Using ImageUltra Builder - IBM Redbooks

Front cover 

ThinkVantage 

Technologies: 

Using ImageUltra Builder 

Overview of ImageUltra Builder 

ImageUltra Builder installation 

Customization and usage 

Eleanor Howard 

Ive Mattheessens 

John Zywicki 

Byron Braswell 

ibm.com/redbooks Redpaper

International Technical Support Organization 

ThinkVantage Technologies: Using ImageUltra Builder 

November 2004

Note: Before using this information and the product it supports, read the information in “Notices” on page v. 

First Edition (November 2004) 

This edition applies to Version 2.01 of IBM ImageUltra Builder. 

This document created or updated on November 12, 2004. 

© Copyright International Business Machines Corporation 2004. All rights reserved. 

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule 

Contract with IBM Corp.

Contents 

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v 

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi 

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

The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 

Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii 

Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii 

Chapter 1. ImageUltra Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.1 Image management today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.1.1 Current tools and procedures used to build and deploy images. . . . . . . . . . . . . . . 2 

1.1.2 Image complexity leads to image management problems . . . . . . . . . . . . . . . . . . . 2 

1.2 Image management using ImageUltra Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.3 Image creation preparation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

1.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.3.2 Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.3.3 Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.3.4 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.4 Installing ImageUltra Builder V2.01. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

1.4.1 Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

1.4.2 Installation procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

1.5 ImageUltra Builder components and basic operations . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

1.5.1 ImageUltra Builder terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

1.5.2 Image types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

1.5.3 The use and importance of Microsoft Sysprep . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

1.5.4 Which image type is best for you? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

1.5.5 Module categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

1.5.6 Module Window Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

1.6 ImageUltra Builder process to create a Smart Image . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

1.7 Create a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

1.8 Import IBM Preload modules into your repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

1.8.1 Importing modules from an IBM recovery CD set . . . . . . . . . . . . . . . . . . . . . . . . . 22 

1.9 Create custom modules - preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

1.9.1 Windows Installer - msiexec.exe file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

1.9.2 InstallShield. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

1.10 Creating an application module from source files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

1.11 Creating a device driver module from source files . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

1.11.1 Install SoundMAX audio driver from a setup.exe file . . . . . . . . . . . . . . . . . . . . . 32 

1.11.2 Install SoundMAX audio driver from an INF file . . . . . . . . . . . . . . . . . . . . . . . . . 37 

1.12 Create a filter/utility module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

1.12.1 Example of a filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

1.13 Creating an operating system add-on module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

1.14 Creating a partitioning module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

1.15 Creating a base operating system hardware specific module. . . . . . . . . . . . . . . . . . . 48 

1.15.1 Create and prepare the image file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

1.15.2 Add the donor image to the ImageUltra Builder repository . . . . . . . . . . . . . . . . . 48 

1.15.3 Setting the module attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

1.15.4 Build the module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

1.16 Create a base operating system Portable Sysprep Image . . . . . . . . . . . . . . . . . . . . . 54 

© Copyright IBM Corp. 2004. All rights reserved. iii

1.16.1 Installing the IBM Customization Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

1.16.2 Create the portable-sysprep image on a source computer. . . . . . . . . . . . . . . . . 55 

1.16.3 Add the donor image to the ImageUltra Builder Repository . . . . . . . . . . . . . . . . 57 

1.16.4 Setting the module attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

1.16.5 Build the module from the image files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

1.17 Customize an Ultra-Portable operating system module . . . . . . . . . . . . . . . . . . . . . . . 63 

1.18 Create your base map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 

1.18.1 Base map settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

1.19 Create a driver map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 

1.19.1 Driver Map settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

1.20 Deploying images using ImageUltra Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

1.20.1 Creating an ImageUltra Builder boot diskette . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

1.20.2 Creating a bootable Network Deployment CD from a diskette . . . . . . . . . . . . . . 86 

1.20.3 Creating a custom network boot diskette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 

1.20.4 Deployment methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 

1.21 Using ImageUltra Builder and Symantec DeployCenter together . . . . . . . . . . . . . . . . 93 

1.21.1 Overview of Symantec DeployCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

1.22 Image development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

1.22.1 Create your donor image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

1.22.2 Use PXE and Virtual Boot Environment to capture donor image . . . . . . . . . . . . 95 

1.22.3 Confirm that you have installed the PXE service correctly . . . . . . . . . . . . . . . . . 96 

1.22.4 Confirm you have the correct Network drivers installed in boot disk builder. . . . 96 

1.22.5 Add the CAPTURE IMAGE.VFD to the Configuration Utility. . . . . . . . . . . . . . . 107 

1.22.6 Add CAPTURE IMAGE selection to the PXE Client menu . . . . . . . . . . . . . . . . 107 

1.22.7 Capturing the donor image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

1.22.8 Add the donor image to the ImageUltra Builder repository . . . . . . . . . . . . . . . . 108 

1.22.9 Create a ImageUltra Builder Smart Image using the donor image as a base. . 109 

1.22.10 Re-clone an ImageUltra Builder after the Smart Image has been deployed into the 

Service Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

1.23 Image deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 

1.23.1 Unicast a cloned ImageUltra Smart Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 

1.23.2 Multicast a cloned IUB Smart Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 

1.24 Software integration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 

1.24.1 Integration with Web-D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 

1.24.2 Integration with System Migration Assistant (SMA) . . . . . . . . . . . . . . . . . . . . . 121 

1.24.3 Integration with Software Delivery Assistant (SDA) . . . . . . . . . . . . . . . . . . . . . 122 

1.24.4 IBM Rescue and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 

1.24.5 ImageUltra Builder with Symantec Ghost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

1.25 Business case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

1.25.1 Example organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

1.25.2 Business case section 1 of 3: Using hardware specific images . . . . . . . . . . . . 131 

1.25.3 Business case section 2 of 3: Using portable-sysprep images. . . . . . . . . . . . . 134 

1.25.4 Business case section 3 of 3: Using ultra-portable . . . . . . . . . . . . . . . . . . . . . . 140 

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 

Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

iv ThinkVantage Technologies: Using ImageUltra Builder

Notices 

This information was developed for products and services offered in the U.S.A. 

IBM may not offer the products, services, or features discussed in this document in other countries. Consult 

your local IBM representative for information on the products and services currently available in your area. Any 

reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, 

program, or service may be used. Any functionally equivalent product, program, or service that does not 

infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to 

evaluate and verify the operation of any non-IBM product, program, or service. 

IBM may have patents or pending patent applications covering subject matter described in this document. The 

furnishing of this document does not give you any license to these patents. You can send license inquiries, in 

writing, to: 

IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. 

The following paragraph does not apply to the United Kingdom or any other country where such provisions 

are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS 

PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, 

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, 

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of 

express or implied warranties in certain transactions, therefore, this statement may not apply to you. 

This information could include technical inaccuracies or typographical errors. Changes are periodically made 

to the information herein; these changes will be incorporated in new editions of the publication. IBM may make 

improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time 

without notice. 

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any 

manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the 

materials for this IBM product and use of those Web sites is at your own risk. 

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring 

any obligation to you. 

Information concerning non-IBM products was obtained from the suppliers of those products, their published 

announcements or other publicly available sources. IBM has not tested those products and cannot confirm the 

accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the 

capabilities of non-IBM products should be addressed to the suppliers of those products. 

This information contains examples of data and reports used in daily business operations. To illustrate them 

as completely as possible, the examples include the names of individuals, companies, brands, and products. 

All of these names are fictitious and any similarity to the names and addresses used by an actual business 

enterprise is entirely coincidental. 

COPYRIGHT LICENSE: 

This information contains sample application programs in source language, which illustrates programming 

techniques on various operating platforms. You may copy, modify, and distribute these sample programs in 

any form without payment to IBM, for the purposes of developing, using, marketing or distributing application 

programs conforming to the application programming interface for the operating platform for which the sample 

programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, 

cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and 

distribute these sample programs in any form without payment to IBM for the purposes of developing, using, 

marketing, or distributing application programs conforming to IBM's application programming interfaces. 

© Copyright IBM Corp. 2004. All rights reserved. v

Trademarks 

The following terms are trademarks of the International Business Machines Corporation in the United States, 

other countries, or both: 

Eserver® 

Eserver® 

ImageUltra 

NetVista 

Perform 

Redbooks (logo) 

Redbooks 

Rescue and Recovery 

The following terms are trademarks of other companies: 

vi ThinkVantage Technologies: Using ImageUltra Builder 

ThinkCentre 

ThinkVantage 

UltraPort 

Update Connector 

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, 

Inc. in the United States, other countries, or both. 

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the 

United States, other countries, or both. 

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other 

countries, or both. 

UNIX is a registered trademark of The Open Group in the United States and other countries. 

Linux is a trademark of Linus Torvalds in the United States, other countries, or both. 

Other company, product, and service names may be trademarks or service marks of others.

Preface 

ThinkVantage Technologies bring your IBM® PCs one step closer to being self-configured, 

self-optimizing, self-protecting, or self-healing, to help save you time and money throughout 

the life of your systems. In short, ThinkVantage Technologies let you focus your attention on 

your business, rather than on your computer. 

ThinkVantage Technologies are software tools designed to help customers drive down IT 

support costs (in particular, the cost of a PC in managing and supporting systems after its 

initial purchase), increase security and decrease the complexity of today’s IT infrastructure. 

This IBM Redpaper will help you install, tailor and configure the IBM ImageUltra Builder 

ThinkVantage Technology. 

The team that wrote this Redpaper 

This Redpaper was produced by a team of specialists from around the world working at the 

International Technical Support Organization, Raleigh Center. 

Byron Braswell is a Networking Professional at the International Technical Support 

Organization, Raleigh Center. He received a bachelor’s degree in Physics and a master’s 

degree in Computer Sciences from Texas A&M University. He writes extensively in the areas 

of networking and host integration software. Before joining the ITSO four years ago, Byron 

worked in IBM Learning Services Development in networking education development. 

Eleanor Howard is a Large Enterprise Field Technical Support Specialist and has worked for 

IBM France for over six years. She covers France, Belgium and Luxembourg. Her areas of 

expertise include providing pre-sales support for ThinkCentre, the IBM Desktop range, and 

IBM ThinkVantage tools, in particular ImageUltra Builder. She also works hand in hand with 

IBM Global Services to develop implementation services for customers around ThinkVantage 

tools. 

Ive Mattheessens is a Software Engineer with the EMEA IBM Imaging Technology Center in 

Greenock, UK. He has worked on the ImageUltra solution development for several large 

international customers in the EMEA region. He specializes in system and application 

deployment technologies and has several years of experience with ImageUltra, Software 

Delivery Assistant and Rescue and Recovery. Before joining the IBM Image Technology 

Center, he worked in IBM Technical Support. He has been employed with IBM for nine years. 

Goran Wibran is a Segment Manager for IBM TCO and ThinkVantage technologies, based in 

Research Triangle Park, NC, USA. His mission is to help IBM PCD create solutions for cost- 

and resource-effective IT management, IT process automation and IT system integration. He 

is one of IBM's leading experts on deploying and managing PC-based products. In his 

leadership role, he works with the IBM Development teams to create the next generation PC 

and Server management solutions. He simultaneously continues his work as a consultant, 

helping IBM customers to develop and implement automated IT processes around the world. 

John Zywicki is a Systems Management Professional with IBM Global Services US. He has 

13 years of experience in all aspects of PC management, deployment and project leadership 

for large enterprise accounts. He is a technical project management lead for hardware and 

software standardization methods, global deployments and systems management solutions. 

His specialties include process development, technical guidance, and solutions development. 

© Copyright IBM Corp. 2004. All rights reserved. vii

He has co-authored three ThinkVantage Technology Redbooks. He is also responsible for 

providing pre-sales and post-sales support and training to IBM internal teams and customers. 

Become a published author 

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with 

specific products or solutions, while getting hands-on experience with leading-edge 

technologies. You'll team with IBM technical professionals, Business Partners and/or 

customers. 

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, 

you'll develop a network of contacts in IBM development labs, and increase your productivity 

and marketability. 

Find out more about the residency program, browse the residency index, and apply online at: 

ibm.com/redbooks/residencies.html 

Comments welcome 

Your comments are important to us! 

We want our papers to be as helpful as possible. Send us your comments about this 

Redpaper or other Redbooks in one of the following ways: 

► Use the online Contact us review redbook form found at: 

ibm.com/redbooks 

► Send your comments in an email to: 

redbook@us.ibm.com 

► Mail your comments to: 

IBM Corporation, International Technical Support Organization 

Dept. HZ8 Building 662 

P.O. Box 12195 

Research Triangle Park, NC 27709-2195 

viii ThinkVantage Technologies: Using ImageUltra Builder

Chapter 1. ImageUltra Builder 

1 

IT departments are usually faced with the demanding task of building workstations for their 

end users. In addition, most business units have different requirements to perform their jobs. 

For an IT department to be successful, it must team with its users to identify what information, 

software and tools need to be loaded on a workstation. 

One of the most popular ways of distributing this information is through the use of images 

which contain the contents for a workstation. Through the use of images, corporations can 

ensure their PCs are consistently functional without having to load every machine individually. 

IT departments use images to control the versions of software and drivers used throughout a 

company. 

ImageUltra Builder is a unique tool that provides IT Departments with an easy-to-use 

interface which centralizes the creation, maintenance and deployment of all their images. 

The following sections will take you through how the modular approach of ImageUltra 

Technology will help you manage all your corporate images within one unique interface. We 

will also discuss how ImageUltra Builder interacts with other image management tools such 

as Microsoft Sysprep and Symantec DeployCenter. 

© Copyright IBM Corp. 2004. All rights reserved. 1

1.1 Image management today 

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 create images on source computers, extract the images and 

store them in a central location. They then 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 

their company. 

1.1.1 Current tools and procedures used to build and deploy images 

Unattended Installation - Scripted 

► Unattended installations can be either a CD based installation or an over-the-network 

installation on to the hard disk drive in a PC. 

► Can be fully unattended or partially unattended using Answer files created using the 

UNATTEND.TXT file 

► Answer files determine what defaults to provide or what information to allow users to 

provide (user name, domain etc.) 

► Downside, can take hours to install 

► High technical knowledge needed to create and maintain scripts. 

► Distribution hardware requirement in an “over-the-network installation” environment 

► Upside, can support multiple hardware 

Disk Duplication - Cloning 

Some companies use cloning utilities to create and deploy their images. First, they create an 

image file that contains the contents of a drive. That image is then loaded onto different 

machines in a corporate environment. 

► Primary benefit is to provide consistency of corporate desktops. 

► Can be either CD based installation or an over-the-network installation. 

► Must use 3rd party utility such as Symantec DeployCenter or Symantec Ghost to make 

drive or partition images. 

► Cloning is supported by Microsoft when used in conjunction with Sysprep. For more 

information on Sysprep see section on “The use and importance of Microsoft Sysprep” on 

page 11. 

► Downside, one clone image for one system model 

► Clone images are effected by chipset level changes 

► Upside, install can be very quick 

1.1.2 Image complexity leads to image management problems 

Keeping and maintaining images can quickly become very difficult as organizations get more 

complex. The number of languages, hardware types and operating systems can increase the 

number of images exponentially, making it difficult to maintain. 

The major challenges most IT departments face are as follows: 

2 ThinkVantage Technologies: Using ImageUltra Builder

► Reduction of time required to create and test images. Different departments have varying 

levels of complexity in the image. These varying needs of different groups in an enterprise 

often result in manual installation of applications by IT staff 

► Finding ways to build and deploy images across a wider range of hardware. 

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

► Use of multiple Operating Systems increases deployment and help desk costs and 

support for multiple languages required by large multinational companies increases 

complexity and cost of large rollouts 

► Users make unauthorized modifications to their standard image(s), generating increased 

help desk calls and requiring additional IT time to re-image PCs 

► Over time, images have to be updated or rebuilt from scratch 

1.2 Image management using ImageUltra Builder 

The purpose of the ImageUltra Builder program is to provide IT departments with 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 tree structures called 

maps to construct your images. These images (referred to as Smart Images, see 1.5.1, 

“ImageUltra Builder terminology” on page 9 and 1.6, “ImageUltra Builder process to create a 

Smart Image” on page 17) can then be deployed across a broad range of hardware platforms. 

Each Smart Image component is stored in a central location called a Repository. ImageUltra 

Builder creates and uses the IBM service partition for deployment.The service partition 

contains different modules for the operating system, applications, and devices drivers, as well 

as a set of recovery tools.The service partition provides its own operating environment which 

is not dependent on the Windows operating system being present on any active partition. For 

non-ibm hardware, ImageUltra Builder will create the service partition for you. 

Figure 1-1 outlines the life cycle of an ImageUltra Image. 

Chapter 1. ImageUltra Builder 3

Operating system, 

application, and device 

driver (opt.) modules 

Import Image 

modules 

Import 

Repository 

Additional drivers, 

application modules 

Build 

Build custom 

modules 

Repository 

Figure 1-1 ImageUltra Builder: life cycle of an ImageUltra Image 

1.3 Image creation preparation process 

The process outlined in this section make the entire imaging process more efficient and 

thorough. The information gathered prior to when the actual image creation project is initiated 

will be very beneficial and make the process more efficient. Once this preparation phase is 

complete, the involved teams will have the information they require to begin the project and all 

future imaging processes will become more organized and simplified, thus eliminating costs 

and fact finding each time a new image is required. 

► Determine the project scope, deliverables and schedules. Communicate this to all involved 

parties. 

► A list of contact names and responsibilities for all team members should be created. 

► A list of all global customer locations should be created. 

► Allocate the standard hardware for image creation, testing and support. 

► Outline the imaging and ThinkVantage tools that will be used in the image creation 

process and that will be installed on the PCs. 

– ImageUltra Builder for imaging 

– Rescue and Recovery for backup and recovery 

– System Migration Assistant for transferring user settings 

– Web-D and Software Delivery Assistant for post imaging application installations 

– Access Connections and Active Protection System for IBM laptops (mobile computers) 

– Update Connector for IBM driver updates 

– Embedded Security Subsystem for security 

4 ThinkVantage Technologies: Using ImageUltra Builder 

Create Image layout 

Drag-n-drop modules 

Maps 

Deply 

Image 

modules to 

Service 

Partition 

Deploy, 

Install

1.3.1 Hardware 

– Access IBM for support and system information 

► Organize communication team meetings to discuss the project during each phase. 

– Connectivity 

There are several steps that need to be taken before the technical teams can become fully 

engaged. Completing these up front will save time and effort once the project begins. All 

engaged team members should be setup with the following if applicable: 

► Security IDs 

► Network IDs 

► Remote access IDs and software 

► Badges 

► Server location information supplied to all the team members. This would include project 

required server share names, application and storage shares. 

If this has not been previously outlined, create a static location for all software and image 

storage. This will keep consistent all images, testing software and documentation. 

This section outlines the current and future PC hardware infrastructure. 

► Create an outline of the current standard PC hardware and all legacy systems that are to 

be supported. This should include: 

– Make/Manufacturer 

– Model 

– Part number 

– A ratio of each model in production and if location or business units have unique 

hardware. 

– Specifications for each model 

– Determine if the hardware standards are standard models or if custom modifications 

been made. If true, what has been added or removed. 

► Document information on where PCs are being purchased. 

– Manufacturer direct 

– A supplier 

► Create an information package on the PC ordering schedule. This will help determine the 

imaging schedule for new image or image updates. 

– Orders are placed every quarter 

– Orders are placed Ad-hoc 

► Determine a schedule for evaluating new PC models. This will also help your image 

creation schedule. 

– Every quarter 

– Every year 

– Determined by manufacturer roadmap 

– Is there a standard product family, such as ThinkPad or ThinkCentre. 


1.3.2 Image 

► Determine if a driver catalog will be maintained for all production PC models and stored on 

local server. This can be done for IBM PCs by using the ImageUltra Builder driver maps or 

the Update Connector ThinkVantage products. 

The image section helps determine the expectations and requirements for creating an image. 

It would be a best practice to determine which PC models and operating systems shall be 

maintained in the current and future environments. 

► Which operating system will be required for imaging 

– The Service Pack level 

– Patches, updates 

– Languages required 

– The PC model/s that this image will support 

– Acquire all operating system source and application licenses. 

► Create an outline providing all specific OS configuration settings and/or preferences.This 

is the most time consuming aspect of the image creation process and having a detailed 

checklist will make this more efficient. Listed are a few examples of the information that 

should be gathered. 

– Partitioning structure 

– FAT32 or NTFS 

– Standard applications installed 

Determine application groups for ImageUltra Builder Maps 

– Security settings 

User 

System 

– Directory structure - User Data 

– Configuration settings 

► Document all image specific settings for support reference and version control. 

– Version, language, patches, build name. 

– Create a unique image version identifier on your build for reference if needed. 

This can be done by editing the oeminfo.ini file for example and having this locally 

on each user PC. 

► Determine which ImageUltra imaging type will be used to create the image 

– You can use one type or a combination of all depending on your requirements 

► Determine if a copy of the image will be stored in a hidden partition on the target system. 

This can be done with IBM tools on IBM systems. 

– You can choose to have ImageUltra Builder copy all the image modules to a hidden 

partition on the PC. 

– Use IBM’s Rescue and Recovery to create a backup of the entire image and create 

incremental backups 

► Outline a final testing and approval process for the image prior to release into production. 

► Determine a schedule for image updates or maintenance. 


1.3.3 Applications 

1.3.4 Distribution 

– How often will this be required 

Quarterly 

Monthly 

– Log and test any required future changes to the image. 

Changes to configuration 

New standard applications or version updates 

Service Packs 

Patches 

Security updates 

Driver updates 

► Communicate to the end user the data backup and recovery strategy 

– IBM Rescue and Recovery 

– IBM System Migration Assistant for user specific settings 

The application section covers the standard or unique applications on the production images. 

► Create a matrix of all standard applications required on each image. 

– Determine an application owner contact for supporting each application. 

– Required languages 

– Required versions 

– Specific location/region applications 

– Business Unit specific applications 

– Acquire all application source and licenses. 

– Verify that the application is certified to run on the standard image operating system. 

► Determine if or which applications will need packaged installations for the image. All the 

applications will need to install silently using the ImageUltra Builder, Software Delivery 

Assistant or Web-D products. 

► Create installation and configuration instructions for each application. 

► Determine an application testing and approval process for release on an image or stand 

alone distribution. 

The distribution section covers the integration of the image once approved for production. 

► Determine the ImageUltra Builder distribution method for the image. 

– CD or DVD media 

– LAN 

– WAN 

– All 

► If required, provide a storage location for archiving legacy images. 


► Determine the location of image integration. Several scenarios can be used depending on 

new product rollouts or rebuilds. 

– Locally 

– A supplier 

– IBM Image and Technology Center 

► Determine a software distribution method for ad-hoc updates 

– Security updates 

– Hardware BIOS or driver updates 

IBM Update Connector 

IBM RDM 

– Manufacturer patches or updates 

Access IBM 

– Application updates 

1.4 Installing ImageUltra Builder V2.01 

ImageUltra Builder is a purchased product and not available via download. 

1.4.1 Minimum Requirements 

The following information provides the minimum requirements for the ImageUltra Builder 

console (the computer on which you install the ImageUltra program): 

► Operating system: Windows XP Professional Edition or Windows 2000 

► Disk Space: 100 MB of available disk space to install the ImageUltra Builder program. 

► Additional storage is required for the repository, which can be on the ImageUltra Builder 

console or on a shared disk. 

► The amount of disk space required for the repository depends on the size and number of 

modules that will be stored in it. Repositories cannot span drives, so make sure you have 

enough storage for future growth. 

Removable-media drives: 

► CD or DVD drive for installation 

► Diskette drive for the creation of Network Deployment Diskettes and Import Diskettes 

► CD-RW drive for CD deployment 

► Minimum networking speed: 10 Mbps; Ethernet or token ring 

1.4.2 Installation procedure 

1. After executing the installation file, you will see the ImageShield Wizard for IBM 

ImageUltra Builder. 

2. Click Next. 

3. At the Welcome to the IBM ImageUltra Builder Setup window, click Next. 

4. Click Yes to agree to the license agreement to continue the installation. 

5. Select the installation directory. Click Next. 


6. Click Finish to complete the installation process. 

7. Install ImageUltra Builder Patch 3.0. For the list of problems solved by this update please 

refer to the README.TXT file. 

Download the patch and readme.txt from the following URL: 

http://www.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-53846 

1.5 ImageUltra Builder components and basic operations 

This section describes the various processes and components associated with the 

ImageUltra Builder program and how they relate to each other. For more step-by-step 

instructions on how to complete any of the processes described in this chapter, refer to the 

ImageUltra Builder help system. 

Think of ImageUltra Builder technology as a mechanism for storing individual operating 

systems, applications, drivers and image utilities into separate bins that can be combined to 

deploy images in multiple combinations. Each separate item is easily accessible for updating 

and maintaining without having to modify or recreate an entire new image. This is the 

modular approach that ImageUltra Builder technology uses to simplify image creation, 

maintenance and deployments. The master bin that contains all of the modules is called a 

repository. The individual items are called modules. 

Important: A module is a packaged, compressed, self-contained unit that 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. 

The repository stores all the modules and deployment maps into a central location. 

1.5.1 ImageUltra Builder terminology 

The following is a high-level description of the ImageUltra Builder terminology: 

► Smart Image: An image that includes intelligence to configure itself based on operating 

system, language, hardware configuration, and user application sets. 

► Repository: Contains all the ImageUltra Builder maps and modules necessary to build 

your Smart Image. 

► Module: A reusable installation package for a single operating system, application, or 

device driver. 

► Container: Special type of module that allows you to group other modules together into a 

single identifier. All modules must be of the same type. 

► Base Map: Defines the menu structure and modules (operating systems and applications) 

contained in a Smart Image. 

► Driver Map: Defines the device driver modules contained in a Smart Image. 

► Filter: Runs during the installation process and allows you to automate decisions. Filters 

are DOS programs that have a true or false return value. 

► Utility: Utilities are DOS programs that run during the service partition boot. ImageUltra 

Builder does not have any built-in utilities, but they are easy to create. 

► Network Sync: Network synchronization occurs at deployment and at first boot. It allows a 

client with a Smart Image to look for updated maps on the “network” (in the repository). 


1.5.2 Image types 

► IBM Customization Program: Program used to create semi-portable Smart Images 

(Sysprep). 

► Hardware Independent Imaging Technology (HIIT): Intelligently detects the correct 

driver base to install for IBM desktops and IBM laptops. 

► Hidden Protected Area (HPA): A hidden area on new model IBM desktop or laptop hard 

disks. The Hidden Protected Area, also referred to as parties, enables IBM to provide a 

disk-based recovery solution that provides greater flexibility and enhances the security for 

recovery data, diagnostics, and potential future applications. 

► Build: Used when testing a module or map in ImageUltra builder. The map or module can 

be edited or changed. 

► Promote: Used after a map or module has been thoroughly tested and is ready for 

production. Once a module is promoted to the gold state, it is locked and you can no 

longer make changes to that module. Promoting a module to the gold state helps ensure 

that the module will not be changed accidentally. 

► Import: Imports maps or modules from another source into your repository. This can be 

from a set of IBM Recovery CDs, a directory, another repository, a service or IBM Hidden 

Protected Area (HPA) partition. 

► Export: Exports maps or modules from a repository to an archive directory. 

► Deploy: Creates a network boot floppy used during deployment or creates the file 

structure needed to create a set of distribution CDs. 

► Replica: A copy or reproduction of work. 

There are three basic image types supported within the ImageUltra Builder tool. They are 

described below. 

► Ultra-portable image: This type of image is installed via a Windows unattended process 

and contains hardware-independent operating-system modules developed by IBM. 

Application modules and device driver modules can be developed by IBM or created using 

the ImageUltra Builder. The IBM created modules can be imported via the hidden 

protected area (HPA), service partition or from a set of recovery CDs. These modules 

enable you to create an image that can be used across the IBM product line of Hardware 

Independent Imaging Technology enabled (HIIT-enabled) personal computers. 

For a listing of IBM HIIT-enabled personal computers, visit the ImageUltra Web site at: 

http://www.ibm.com/pc/support/site.wss/MIGR-44316.html 

► Portable-sysprep image: This type of image is created by a third-party image-cloning 

tool, such as Symantec Ghost or Symantec DeployCenter, but modified by ImageUltra 

Builder tools to enable the installation of additional modules created and managed by 

ImageUltra Builder. An example of this would be a non-hardware dependent cloned 

sysprep operating system that adds model specific drivers and user-specific applications 

after the base operating system is installed. 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 department application 

requirements. 

► Hardware-specific image: This type of image is created by a third-party image-cloning 

tool, such as Symantec Ghost or Symantec DeployCenter. It is a self-contained monolithic 

image, which does not enable the installation of additional modules. All files, applications 

and device drivers are contained within the image itself. The hardware configuration of the 

target computer must be the same as the hardware configuration of the source computer 

used to create the image because of this. 


A hardware-specific image is similar to a portable-sysprep image, but the differences are: 

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

1.5.3 The use and importance of Microsoft 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 created from a 

source computer that has 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. In contrast, ultra-portable images are 

created from modules provided by IBM and are installed via a Windows unattended process. 

If you intend to use ultra-portable images only, the Sysprep tool is not used. 

1.5.4 Which image type is best for you? 

You can use one or all methods depending on your company infrastructure. Here are some 

examples: 

► To maintain existing PCs for which you already have images, you might choose to convert 

existing hardware-specific monolithic images into modules that can be stored and 

deployed using the ImageUltra Builder program. 

► If you are planning to install assorted models of IBM PCs and ThinkPads, you might 

consider developing ultra-portable images that can be used across the IBM product line 

regardless of hardware variations. 

► If you plan to install a mix of PCs from various manufacturers, 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. 

All three image types can be used by a corporation, as can any combination of the image 

types. 

Figure 1-2 outlines the basic differences between the three image types. 


Function 

Figure 1-2 ImageUltra Builder Image Differences 

The following is a list of functions available for each image type: 

► Portability 

– A hardware-specific image is only for use on identical computers systems. 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. 

– Although portable-sysprep images can be used with IBM and non-IBM 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. 

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. 

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. 

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. 

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


Ultra Portable Portable Sysprep System Specific 

Portability High Medium-High None 

Effort to maintain image None Medium High 

Need for image updates Low Medium High 

Installation time 

Image Type 

Integrated with HIIT modules and 

ImageUltra Builder modules 

50 min + (Windows 

unattended install) 

20 min + (Sysprep) 15 min + (Sysprep) 

Yes Yes No 

Supported operating systems Win2000, WinXP Win2000, WinXP Any operating system 

Supported hardware IBM Only IBM and non-IBM IBM and non-IBM

The high portability of the ultra-portable image is limited to IBM personal computers 

only. The same base module and most application modules can be used across the 

IBM personal computer product line of HIIT-enabled computers, regardless of 

hardware variations. 

► Image maintenance 

The ultra-portable and portable images require less maintenance since they use the 

modular approach to image creation. The hardware specific image requires a high amount 

of maintenance due to having all applications, drivers, patches etc. contained within one 

monolithic image. Each time a change is required, the entire image must be modified. 

► Installation time 

The installation time varies between the three image methods. The hardware-specific 

image is the quickest due to having all the software components included within the image 

itself. The portable-sysprep image has the operating system cloned but the applications 

and drivers to be installed can be different depending on the hardware model and user 

application requirements. The ultra-portable has the slowest deployment time due to using 

an unattended installation instead of cloning technology. 

► Hardware Independent Imaging Technology (HIIT) Integration 

The ultra-portable and portable-sysprep image can automatically detect the model type of 

most IBM computers and install the drivers required for each system. The 

hardware-specific image does not provide this feature. 

► Supported operating systems 

The ultra-portable and portable-sysprep images will only be supported with Windows 2000 

images and Windows XP images. The hardware specific image can be used with any 

operating system due to no modules or add on drivers being supported. 

► Supported hardware 

The ultra-portable image is only supported for use on IBM PCs and ThinkPads. The 

operating system modules were created for IBM systems only. Using the ultra-portable 

image on a non-IBM may violate software license agreements. 

The portable-sysprep and hardware-specific can be used on IBM and non IBM systems. 

1.5.5 Module categories 

In this section are the descriptions of the modules used within the ImageUltra Builder tool. 

► 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 base operating system. Base operating system modules include 

modules created from hardware-specific images and portable-sysprep images, as well 

as base operating-system modules imported from the service partition or Hidden 

Protected Area of a source IBM computer. Base operating-system modules are 

typically created by and installed through an imaging tool, such as Symantec Ghost or 

Symantec DeployCenter. An example of this would be an operating system module for 

Window 2000 or Windows XP. See 1.15, “Creating a base operating system hardware 

specific module” on page 48. 

– Operating system add-on 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. See 1.13, “Creating an operating 

system add-on module” on page 39. 

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

the C partition, or delete one or more pre-existing partitions. 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 tool, such as Symantec Ghost or Symantec DeployCenter. 

See 1.14, “Creating a partitioning module” on page 47. 

► Application modules: Each of these modules contains all of the components associated 

with a specific application program. Software applications such as Microsoft Office, Adobe 

Acrobat and IBM System Migration Assistant would be separate application modules. See 

1.10, “Creating an application module from source files” on page 28. 

– If you are building an ultra-portable image or a portable-sysprep image, you can use 

application modules. 

– If you are building a hardware-specific image, you cannot use application modules 

when deploying the image. All applications must have been previously contained within 

the hardware-specific image when it was created. 

► Device driver modules: Each of these modules contains all of the components 

associated with a specific device driver. There would be a separate device driver module 

for the IBM ThinkPad video driver or a ThinkCentre audio driver for example. 1.11, 

“Creating a device driver module from source files” on page 32. 

– If you are building an ultra-portable image or a portable-sysprep image, you can use 

device-driver modules. 

– If you are building a hardware-specific image, you cannot use device-driver modules in 

conjunction with that image. All device drivers must be contained within 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. 

► Container 

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. The use of containers is optional, but you might find 

containers helpful when creating maps because you can simply inserting the container 

module into your map instead of inserting each individual module. 

► Filters 

Filters automate a decision during the installation process. You typically use filters to 

obtain hardware-related information from a target computer to determine if a specific 

module or set of modules should be installed. The ImageUltra Builder program provides 

filters that check the machine type, machine type and model number, hardware platform 

(mobile or desktop), and whether or not a computer is an IBM computer. You can also 

develop your own filters if needed. 

Filters are DOS-based programs that run during the installation process. In most cases 

filters query the BIOS of the target computer, but they can query other devices that store 

identification information in a ROM or EEPROM module. For example, you might want to 

check for the presence of a PCI modem before installing a modem-related application 

program or you might want to check for a specific machine type to determine which device 

drivers should be installed. 


► Utilities 

Utilities are DOS-based EXE, BAT, or COM files that run during the installation process. 

For example, an installer might want to run CHKDSK to determine the size and condition 

of a hard disk before any files get installed. Utilities are copied to the service partition of 

the target computer during deployment, run during the installation process, but never get 

copied to the active partition of the target computer. You can incorporate utilities in a map 

to run immediately before the installation menus, immediately after the installation menus, 

or as a result of a selection in the installation menus. You determine how the utilities run 

and in what order. 

The ImageUltra Builder program does not provide any utilities. If you want to include 

utilities, you will have to build your own utility modules. 

To use a utility, you either assign a utility module to a base-map menu item or use the 

Before/After Menu tab in the Map Settings window for base maps. 

► Base map 

A base map is a deployment repository that contains only the operating systems, add on, 

partitioning and application modules that are required for a unique deployment. This can 

be accessed through the base maps tab in the ImageUltra Builder application. The base 

map is used to organize modules for deployment to install by language, business unit or 

any other business specific map that you create. 

For example, you can create a base map named “XP Standard” that would include a US 

English Windows XP portable-sysprep module, the standard application modules that are 

required on every computer in your corporation and any other add on, partition, filters, 

container modules that are required. Modules can be copied from the main repository to 

any or all base maps thus giving a corporation one location to store their images. 

For conceptual information about developing base maps, refer to the ImageUltra Builder 

Version 2.0 User Guide. 

► Driver map 

A driver map is the menu driven area that contains all of the driver modules. This can be 

accessed through the driver map tab in the ImageUltra Builder application. This can be 

used to insert all the driver modules for a model specific system under one map heading. 

The IBM ThinkPad T40 2373-75U driver map, for example, could contain the audio, video 

and network driver modules. This can either be setup to display a manual menu selection 

window during installation or a filter can be added to automatically select which drivers the 

system requires. 

► Repository 

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 that you create. The actual file names displayed in My Computer or a DOS window 

are assigned by the ImageUltra Builder program. The following is a list of file extensions 

and description used for the files in the repository: 

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

Builder interface. 

– .DMA: Driver maps 

– .BMA: Base maps 

– .IMZ: Compressed module source 


1.5.6 Module Window Tabs 

When creating and adding modules to the ImageUltra Builder repository, a window with 

multiple tabs will be presented allowing you to describe various properties for the module. 

Refer to Figure 1-21 on page 30. Following is a description of those tabs. 

General Tab 

The general tab allows you to enter general information about the module. Module name, 

version number, description of module, and there is even a field to encrypt your module. 

Languages Tab 

By checking a language and operating system box, ImageUltra Builder will check the 

operating systems and language during the deployment stage; if there is no match, the 

module will not be deployed. 

Source Tab 

In the source tab you detail all commands and files necessary to the execution of a module. 

► In the Source directory field, browse to the directory where the source file for this 

application is located. Example: C:\apps 

► In the Silent install command field, browse to the executable file contained in your source 

directory. Example: C:\apps\wrar280.exe 

► In the Parameters field, type your silent install switch. Example: /s. 

► Close the Properties window, and when prompted, select Yes to save. 

Filters Tab 

Filters are usually DOS-based programs. Typically, they will be a .EXE or .BAT file. Once you 

have created your filter modules you can then apply them to other modules. 

Example: Filter ISIBM will run a check to make sure the hardware this module is being 

deployed to is an IBM Machine. 

Options Tab 

There are a number of fields on this tab that will allow you to control the installation behavior 

of the module: 

Target location 

These fields define whether the application files should be copied to the target partition. 

If you type a path in this field and you also provide a Silent install command on the source tab, 

the files will be copied to the target partition in addition to the application being installed. 

If you type a path in this field and you do not provide a Silent install command on the Source 

tab, the files will be copied to the target partition, but the application will not be installed 

automatically. 

Behavior 

These fields are used to control the module installation order. 

► Install hook 

– Install during auditboot (Default): This selection enables the module you are 

creating to be installed during the first boot after the Windows setup is complete. 


– Install during customer first boot: This selection enables the module you are 

creating to be installed after the auditboot, upon successful completion of Windows 

setup. 

– Install when customer chooses via desktop shortcut: This selection enables users 

to install the module after the image is installed by clicking a shortcut on the desktop. 

The ImageUltra Builder program copies the module source files to a folder on the user 

partition and creates an icon on the desktop that links to the installation file. 

► Install slot: 

The install slot number determines when a module is installed in relation to other modules 

that are assigned during the same boot cycle. Install slot numbers range from 1 to 9. The 

higher the slot number, the later the module is installed. 

Hardware Independent Imaging Technology (HIIT) behavior 

This field determines how Hardware Independent Imaging Technology behavior is 

implemented during the installation process. This field only applies to modules that you plan 

to include in a driver map. Typically, you do not want to modify this field unless there are 

unique circumstances regarding the module you are creating. The following are the choices 

associated with the HIIT behavior field: 

► Normal device detection: This selection is intended for device-driver modules that are 

used in driver maps. 

► Ignore HIIT processing: This selection is intended for unique application modules that 

are used in driver maps. For example, you might want to include an application that 

contains application files and device drivers. In this case, you can choose to put the 

module in both maps. 

► Always install: This selection is intended for modules in a driver map that fail to install 

correctly during normal HIIT processing. 

For INF installs only 

► INF installable: Mark this check box if the module you are creating is an INF installable. 

This field is typically used for device drivers only. 

► Relative location of INF files in the source: This field is activated only if the INF 

installable field is marked. This field requires an entry if INF files needed for this module 

are not located in the folder defined in the Source directory field of the Source tab. If you 

need to define a path, the path must be a relative path based on the root folder of the 

source files. 

1.6 ImageUltra Builder process to create a Smart Image 

The following ImageUltra Builder process steps to create a Smart Image are covered in more 

detail in the referenced sections: 

► Create a repository (refer to 1.7, “Create a repository” on page 18) 

► Import IBM Preload modules into your Repository (refer to 1.8, “Import IBM Preload 

modules into your repository” on page 22) 

► Create custom modules - preparation (refer to 1.9, “Create custom modules - preparation” 

on page 26) 

► Create an application module from source files (1.10, “Creating an application module 

from source files” on page 28) 

► Create a device driver module from source files (refer to 1.11, “Creating a device driver 

module from source files” on page 32) 


► Create a utility/filter module (refer to 1.12, “Create a filter/utility module” on page 38) 

► Create an add-on operating system module (refer to 1.13, “Creating an operating system 

add-on module” on page 39) 

► Create a partitioning module (refer to 1.14, “Creating a partitioning module” on page 47) 

► Create a base-operating system Hardware Specific module (refer to 1.15, “Creating a 

base operating system hardware specific module” on page 48) 

► Create a base-operating system Portable-Sysprep module (refer to 1.16, “Create a base 

operating system Portable Sysprep Image” on page 54) 

► Customize an Ultra-Portable operating system module (refer to 1.17, “Customize an 

Ultra-Portable operating system module” on page 63) 

► Create a base map module (refer to 1.18, “Create your base map” on page 66) 

► Create a driver map 1.19, “Create a driver map” on page 81) 

Once you have completed the above steps you can then deploy your Smart Image to the 

target systems. The following sections will take you through each of the steps in the above 

process. 

1.7 Create a repository 

The first task that must be completed after installing ImageUltra Builder is to create a 

repository. 

1. Open ImageUltra by double-clicking the IBM ImageUltra Builder desktop icon. If this is the 

first time that ImageUltra is opened, the Welcome window will be displayed (see 

Figure 1-3). If the Welcome window is not displayed, click File, then click New 

Repository.... 

Figure 1-3 New Repository welcome window 

Repositories can be imported or created later as needed. 


The “best practice” for the number of repositories for a customer would be the use of one 

repository. By using one repository, the customer can easily pull modules from different 

builds into a new folder for a new system. Multiple repositories are possible and may be 

useful for business partners maintaining images for different customers for example. 

2. After reviewing the Welcome window, click Next. You will see a window similar to 

Figure 1-4. 

ThinkVantage 

Figure 1-4 Create Repository 

Provide a name for the folder that the repository will be stored in. 

Tip: It is recommended that you keep the length (and simplicity) of your directory and 

share locations as short as possible. This reduces the chance for error in your scripts 

and also avoids any “directory length” limitations that might be imposed by the 

operating system. 


3. Click Next. You will see a window similar to Figure 1-5. 

Figure 1-5 Description 

Provide a description for the new repository. 


Figure 1-6 Repository ID 

ThinkVantage 

Since this is the first repository that is created, accept the default repository ID that is 

provided. Click Next. 

Note: This window provides details of what the repository ID is and what it is used for. 


Figure 1-7 Default repository 

Figure 1-8 Insert Folder 

5. Click Finish to complete the creation of the new repository. 

Creating a new folder in the ImageUltra Builder repository 

To keep the repository organized, it is recommended that different folders be created under 

the repository to store modules that are associated with different hardware platform. This 

makes finding and updating modules easier in the future. Since all of the folders are 

contained in the same repository, all of the modules from the different folders will be available 

to create the system build. To create a new folder, perform the following steps: 

1. Open ImageUltra Builder. 

2. Right-click Repository (see Figure 1-7). You will see a window similar to Figure 1-8. 

3. Click Insert. 

4. Click Folder. You will see a window similar to Figure 1-9 on page 22. 


Figure 1-9 New Repository folder 

5. Rename the new folder to a name that is readily associated with the hardware platform 

that include the recovery CD modules (see Figure 1-9). In this case, T40_Windows_2000 

is the name of the folder where the T40 ThinkPad Windows 2000 Professional recovery 

CDs will be imported. 

In the next section, we begin preparing the source files for a module. 

1.8 Import IBM Preload modules into your repository 

There are several ways of importing IBM Modules into your repository. The quickest and 

easiest way to import these modules is to use a recovery CD set provided by IBM. The 

recovery CDs contain all of the software including operating system, hardware device drivers 

and applications that come preloaded on an IBM system. 

1.8.1 Importing modules from an IBM recovery CD set 

1. Create a new folder in your repository. 

2. From the main menu click the Import button from the menu. You will see a window similar 

to Figure 1-10 on page 23. 


Figure 1-10 Import wizard welcome window 

3. Select A set of IBM Recovery CDs. Click Next. 

This same procedure can be used to import modules into the repository from any of the 

sources listed in the figure above. 

4. Insert the first CD of the IBM Recovery CD set. 

Figure 1-11 Import modules - insert CD 



6. Select all of the modules to be imported. Click Next. 

Figure 1-12 List of available modules and maps 

7. Select the destination folder and then click Next. 

Figure 1-13 Destination folder 


Figure 1-14 Import ready to proceed 

8. Click Import to begin importing the selected modules and maps. 

Figure 1-15 Insert CD #2 

9. Insert CD #2. Click OK. 

10.Click Next to begin importing from CD #2. 

11.Select all of the modules to be imported. Click Next. 

12.Select the destination folder and then click Next. 

13.Click Import to begin importing the selected modules and maps. 

14.Insert CD #3. Click OK. 

15.Click Next to begin importing from CD #3. 

16.Select all of the modules to be imported. Click Next. 

17.Select the destination folder and then click Next. 

18.Click Import to begin importing the selected modules and maps. 

Note: If there are existing modules and/or maps in the repository folder that you are 

importing to, you will be prompted by the following window 

If the following window is displayed, click OK. 


Figure 1-16 Overwrite confirmation 

19.Click Finish. 

1.9 Create custom modules - preparation 

Any application, device driver, or add-on operating-system component that you intend to 

deploy as a module must be prepared to perform an unattended/silent installation. This is 

mandatory for all application and device driver packages that you wish to install as part of an 

ImageUltra Builder Smart Image. 

Note: 

► An unattended installation is one which does not require any user interaction. 

► A silent installation is one which does not display any indication of its progress. 

The method used to prepare an application for ‘silent installation varies depending on the 

installation mechanism being used. 

Common tools used to generate silent install packages for your applications or device drivers 

are Windows Installer and InstallShield. We will have a look at both in the following sections. 

1.9.1 Windows Installer - msiexec.exe file 

Msiexec.exe is the Windows Installer executable that runs the Windows Installer service. The 

Windows Installer service installs and manages installation packages written to specific 

standards and stored as a database in files with the .MSI extension. 

The Windows Installer reads the installation database, performs the installation and then 

monitors the installed software to ensure functionality. When an .MSI is opened, msiexec.exe 

reads the data stored in the database and builds an internal script. It then performs the 

actions in the script to complete the installation. Sometimes Install Packages pre-install 

Windows Installer as part of their installation package. 


1.9.2 InstallShield 

A transform is a special kind of Windows Installer file (.MST file) that customizes a Windows 

Installer installation package. You use it to change the installation in some way for a specific 

set of customers or users. 

The Windows Installer service does allow installation package to be installed silently. 

There are four User Interface Levels that can be used while installing a package: 

1. NONE (Completely silent installation) 

2. BASIC (Simple progress bar and error handling) 

3. REDUCED (Authorized UI, wizard dialogs suppressed) 

4. FULL (Authorized UI with wizards, progress bar, errors) 

To run an installation package with silently, you need to use the following command: 

MSIEXEC /i Product.msi /qn 

If your release settings include SETUP.EXE, you can run the following command: 

SETUP.EXE /s /v"/qn" 

Basic MSI projects do not create or read response files. To set installation properties for a 

Basic MSI project, use a command similar to the following: 

MSIEXEC /i Product.msi /qn INSTALLDIR=D:\ProductFolder USERNAME=’Valued Customer" 

See the documentation associated with the specific installation product if you encounter any 

problems. 

InstallShield is a very commonly used application packaging system. Installation packages 

created using InstallShield recognize commands such as /s, /SMS /r etc. The installer itself 

is the setup.exe file. To ensure the application installs silently, you will need to generate a 

response file (.iss file) if one is not already present. Both of these files, plus any other files 

needed to install your package need to be stored in the same folder. 

Figure 1-17 Setup.exe and setup.iss files must be in the same folder 


How to generate a SETUP.ISS file 

1. Copy all source files for the application into an empty folder. Make sure you maintain the 

folder structure that was provided on the software manufacturer’s distribution media. In the 

case of a .ZIP file, make sure you maintain the folder structure when you unzip the file. 

2. Open a command prompt window. 

3. Change to the folder that contains the application SETUP.EXE file. 

4. At the command prompt, type SETUP -R and then press Enter. 

Figure 1-18 Setup - R command to generate a new setup.iss file 

5. Follow the steps to install the program. As you install the program, the keystrokes and 

mouse clicks are recorded in the new SETUP.ISS file. Because the values you type will be 

used on all target computers, you should use company-related information in place of any 

personal information for which you might be prompted. 

6. When the installation is complete, the new SETUP.ISS file will be in the Windows folder 

for Windows XP and the WINNT folder for Windows 2000. 

7. Copy the new SETUP.ISS file from the Windows folder into the folder that contains the 

application SETUP.EXE file. 

Note: Newer versions of InstallShield might involve different steps. 

Now that you have generated all necessary files to silently install your package, you can 

create a module in ImageUltra Builder from these source files. 

1.10 Creating an application module from source files 

For this example we will create an application module based on the application WinRAR. 

Steps to create an application module from your application source files: 

1. Select the Applications tab (Figure 1-46 on page 46). 

2. Right-click the space in the window, select Insert application. 

3. Click Next to create a module. You will see a window similar to Figure 1-19 on page 29. 


Figure 1-19 Create Module window 

4. The module type Application will be pre-selected. Click Next. 

5. In the Name field, type WinRAR. Do not choose to make this module a container. 



7. On the next window, you will be asked if you would like to create this module with the same 

settings as an existing module. Click Next without selecting any modules. 


8. Click Finish to complete the New Module Wizard. 

The properties window for this module will now pop up on the General tab (Figure 1-21). 

Figure 1-21 WinRAR: Application window 

In the Version field, type 2.80. 

9. Select the OS/Languages tab. The window shown in Figure 1-22 will be displayed. 



Under the languages selection, click the relevant Languages and Operating Systems 

boxes that this module will be supported on. In our example we have selected Check All. 

10.Select the Source tab. The window shown in Figure 1-23 will be displayed. 


– In the Source directory field, browse to the directory where all the relevant files needed 

to silently install this application are located. 

– Select your setup executable or your batch file for your application. In our example we 

browse to the wrar280.exe file. 

– In the Parameters field, enter your silent install commands. In our example we have 

used /s which is an install shield command. The /s command will ensure that the 

response file gets called to automate the installation. 

11.Close the Properties window, and when prompted, click Yes to save. 

You will now see the new module under the Applications tab on the main console. 

12.Right-click the module, select Build. 

You will now see a status bar indicating the module building progress. 


When the building process is finished, you will see a window that lists the script files that 

have been created. See Figure 1-24. 

Figure 1-24 List of files associated with this build 

13.Click Finish. The new module has now been created. 

1.11 Creating a device driver module from source files 

In this section, we will create a module that will install a device driver. There are two ways of 

installing a device driver. Either you use a setup.exe file or a information file (INF). 

► A setup.exe file can install the base device driver along with any associated 

mini-applications. 

► An INF file is a text file that specifies the files that need to be present or downloaded for 

your driver to run and allows customization of the installation procedure. 

The following sections show how to install an audio driver using both of these methods. 

1.11.1 Install SoundMAX audio driver from a setup.exe file 

1. Open your ImageUltra Builder Repository and select the location where you wish to create 

your new device driver module. 

2. Select the Device Drivers tab. 

3. Right-click the space in the window, select Insert Device Driver. The New Module Wizard 

will now appear. 

4. Click Next to start creating a module. You will see a window similar to Figure 1-25 on 

page 33. 



Device Driver will be pre-selected. 



6. In the Name field, type SoundMAX Audio Driver. Do not choose to make this module a 

container. 


8. You will now be asked if you would like to create a module, with the same settings as an 

existing module. Do not select an existing module here. Click Next. 


9. Click Finish to complete the New Module Wizard. 

You will now see the module Properties window on the General tab. 

Figure 1-27 SoundMAX Audio Driver: Device Driver 

10.In the Version field, enter 5.12.01.3535. To find the version of the device driver, open the 

INF file associated with your driver. See Figure 1-28. 

Figure 1-28 Device driver version information 


Tip: When creating device driver modules it is highly recommend to enter the version of 

the driver being installed to help you keep track of different driver versions. 

11.In the Family field shown in Figure 1-27, select Audio. 

12.Go to the OS/Languages tab (Figure 1-29). 

Figure 1-29 SoundMAX Audio Driver: Device Driver window 

13.Under the Languages selection, click Check All. Under the Operating Systems selection, 

select Windows 2000, Windows 98, Windows Millennium, Windows XP Home and 

Windows XP Professional. 


14.Go to the Source tab. 

Figure 1-30 SoundMAX Audio Driver: Device Driver window 

15.In the Source directory field, type c:\drivers\win\audio. 

16.In the silent command field, type setup.exe. 

17.In the Parameters field, type -s. 

18.Close the Properties window. When prompted, select Yes to save the module. 

You will see the module under the Device Driver tab on the main console. 

19.Right-click the module, select Build. 

20.When the build process is finished, you will see a window that lists the script files that have 

been created. 

Figure 1-31 Review your scripts window 


21.Click Finish. The module has now been built. 

1.11.2 Install SoundMAX audio driver from an INF file 

1. Repeat steps 1 to 13 above. 

2. Go to the Source tab and type in the location of where the INF file is stored, for example 

C:\Drivers. 

Figure 1-32 Audio driver source file information 


3. Click the Options tab and check the INF installable box. 

Figure 1-33 Check the INF installable box in the Options Tab 

4. Close the Properties window. When prompted, select Yes to save the module. 


5. Right-click the module, select Build. 

6. When the build process is finished, you will see a window that lists the script files that have 

been created. 


7. Right-click the module, select Build. 

8. Click Finish. The module has now been built. 

1.12 Create a filter/utility module 

Filters and utilities are usually DOS-based programs. Typically, they will be a .EXE or .BAT 

file. The process of creating either a filter or utility module is almost the same as for the other 

modules. 

1.12.1 Example of a filter 

In this example we will show how to use the IBM preload filter, IBM Hardware Platform 

Check, in an application module. In our example we will use this filter with the IBM Active 

Protection System application. This will check if the target system is a mobile system. If not, 

this application module will not be installed. 


1. Open the application module. 

2. Click the Filters tab. 

3. Click the insert filter icon and select the ImageUltra 2.0 - IBM Hardware Platform Check 

(ismobile) module as below. See Figure 1-34 

4. Click OK and save the module. 

Figure 1-34 Add ISMOBILE filter to the Active Protection System module 

When would you need to use this filter? For example, an application such as IBM’s Active 

Protection System, which is dependant on mobile hardware, and will not function on a 

desktop system, you can use this filter. 

There are a few differences in the windows you will see: 

► Since they are DOS-based, there is no need to select a supported operating system. 

There is just an option to select a language. 

► On the Source tab, you only specify a source directory and an execution command with 

possible parameters. 

These files do not install, so there is no need to specify a target path. 

1.13 Creating an operating system add-on module 

In this section, we will create an operating system add-on module, for Windows 2000 Service 

Pack 4: 

1. Open the ImageUltra Builder console. 

2. Select the Operating Systems tab. 


Figure 1-35 IUB repository, operating systems tab 

3. Right-click the space in the window and select Insert OS. You will see a window similar to 

Figure 1-36 on page 40. 

Figure 1-36 Create new module wizard 

4. Click Next to create a module. 


Figure 1-37 Create module wizard, module type selection 

5. In Figure 1-37, select Operating System as the type of module to create, then click Next. 

Figure 1-38 Create module wizard, enter name window 

6. In the Name field (Figure 1-38), type Windows 2000 Service Pack 4. Do not choose to 

make this module a container. 

Note: A container is a group of modules. It is used to make the organization of modules 

easier. An example of a container would be a main operating system module, together 

with all patches and hot fixes that apply to it. 



Figure 1-39 Create module wizard, replicate settings window 

For our example, it is not necessary to select an existing module. 


Figure 1-40 Create module wizard, operating system module type selection 

9. Select Add-on operating system module. 


10.Click Next. You will see a window similar to Figure 1-41. 

Figure 1-41 Create module wizard, completion window 

11.Click Finish. You will see a window similar to Figure 1-42. 

Figure 1-42 Module properties, general tab 

12.In the Version field, type SP4. 

Note: You can assign a password to the module; this will prevent the module from being 

unpacked by any process other than an ImageUltra Builder process. 


13.Select the OS/Languages tab. You will see a window similar to Figure 1-43. 

Figure 1-43 Module properties, OS/Languages tab 

14.Under the Languages selection, click Check All. Under the Operating systems selection, 

select Windows 2000. 

Note: The ImageUltra Builder will check the operating systems and language during 

the deployment stage; if there is no match, the module will not be deployed. 


15.Go to the Source tab. You will see a window similar to Figure 1-44. 

Figure 1-44 module properties, Source tab 

16.Click Browse next to the Source directory field, locate and select the c:\win2ksp4\i386 

directory. 

17.Click Browse next to the Silent install command, locate and select update.exe in the 

c:\win2ksp4\i386\update\ directory. 

18.In the Parameters field, type -q -n -z. 

The preinstall command runs before the Silent install command. An example of this would 

be a utility that creates a directory. 

The postinstall command runs after the Silent install command. An example of this would 

be a utility that deletes a shortcut. 


19.Go to the Options tab. You will see a window similar to Figure 1-45. 

Figure 1-45 module properties, Options tab 

20.Change the Install slot to 1. We want the Service Pack to install before any of the other 

modules. 

21.Close the Properties window. When prompted, select Yes to save the module. 

You will now see the new module under the Operating Systems tab on the main console 

(Figure 1-46). 

Figure 1-46 Module creation finished 

22.Right-click this new module, then select Build. 

You will now see a status bar, indicating the module building progress. 

23.When the building process is finished, a window will pop up listing the script files that have 

been created. 


Figure 1-47 Scripts generated 

24.Click Finish. The module has now been created. 

Tip: Once this module has been tested, you will want to promote it to a “gold” state. When 

a module is in gold state, it is locked and no additional changes can be made. This 

prevents unwanted modification of modules you know have been verified for functionality. 

1.14 Creating a partitioning module 

A partitioning module is a special type of operating-system module that has the following 

purposes: 

► To delete one or more user partitions before installing an image 

► To create an additional data partition on the target computer beyond the C partition - see 

section below. 

► To preserve one or more pre-existing data partitions on a target computer 

► To disable the default partitioning behavior of the ImageUltra Builder program 

Important: Understand that the order in which these partitioning modules are installed is 

extremely important. You set the order in the Install Sequence tab of the base-map Map 

Settings window (see “Install Sequence tab” on page 78). 

By default, the ImageUltra Builder program automatically deletes all user partitions on the 

target computer as a starting point for installation. You can override the default behavior or 

make the behavior dependent on a menu selection through the use of partitioning 

modules.The ImageUltra Builder program provides three ready-to-use partitioning modules in 

the root node of the repository. With the help of an imaging cloning tool like Symantec 

DeployCenter, you can also generate your own partitioning modules using script files: 

► DrivePrep - Delete All Partitions: This partitioning module is designed to delete all user 

partitions on the target computer hard disk before the new image is installed. 

► DrivePrep - Delete C Partition Only: This partitioning module is designed to preserve 

pre-existing data partitions on a target computer and use the space previously used by the 

C partition for the new image. 


► DrivePrep - Delete No Partitions: This partitioning module disables all partitioning 

activity generated by the ImageUltra Builder program and is used only in special cases 

with a Portable-Sysprep Image or Hardware-Specific Image that contains all formatting 

and partitioning instructions. 

1.15 Creating a base operating system hardware specific 

module 

Base operating system modules can be created from hardware specific images (industry 

standard images from Symantec Norton Ghost or DeployCenter) or portable-sysprep images. 

1.15.1 Create and prepare the image file 

1. On a source computer, install the Windows operating system that you want on your target 

computers. You can use any file system that you want. 

2. Install any application programs that will be common across all of your target computers. 

3. Use either Symantec DeployCenter or Ghost software to create the image. For more 

information on how to use Symantec DeployCenter with ImageUltra Builder refer to 

Chapter 1.21, “Using ImageUltra Builder and Symantec DeployCenter together” on 

page 93. 

4. Store the image in its own folder. In the case of CD deployment, where you have to 

segment the image into CD-sized files, store all of the files in a single folder. Make sure the 

folder is in a location that is accessible by the ImageUltra Builder console. 

5. Store the image-cloning tool that you used to create the image (Symantec Ghost or 

Symantec DeployCenter) in the same folder as the image file. 

6. Store any batch files or script files that you may have created in the same folder as the 

image file. 

1.15.2 Add the donor image to the ImageUltra Builder repository 

Tip: Refer to the section titled Creating Hardware Specific Images in the ImageUltra help 

file. This section provides useful information on using Symantec Ghost and Symantec 

DeployCenter. 

Complete the following instructions to insert the module: 


2. Select the repository. The location that the modules are placed in is not critical. The 

modules can be moved around and reorganized within the same repository just like files in 

a folder in Windows Explorer. 


3. Click Insert. You will see a window similar to Figure 1-48. 

Figure 1-48 Insert Operating System 

4. Click Operating System. 


6. Select Operating System. 


8. Type a name for this Operating System. For example, type: 

Compaq Deskpro EN Windows 98se - Sales 


Figure 1-49 OS module name 



Figure 1-50 OS module type window 

11.Select Base operating system module. 

12.Select Hardware Specific from the Image Type pull-down menu. 

13.Click Next. 


1.15.3 Setting the module attributes 

Complete the following instructions to edit the hardware-specific OS module: 

1. The Operating System module that was just created will open for editing. If it does not, 

double-click the operating system module located in the right window of the ImageUltra 



Figure 1-51 OS module general window 

2. From the General tab, provide a version number for the newly created module. If this is the 

first version of this particular module, use 1.0.0. 

3. In the Comments box, add text that details what this module is for. The operating system, 

hardware platform, business unit, language, date, who created the original image and who 

created the module for the image would all be useful information to include here. 

4. Click the OS/Language tab. 

Figure 1-52 OS/Language window 


5. Select the languages and operating systems that this OS module supports. For our 

example, we selected English and Window 98. 

6. Click the Source tab. You will see a window similar to Figure 1-53. 

Figure 1-53 Source window 

7. Click Browse of the Source directory field and then select the legacy image file that will be 

deployed using this module. 

8. Click Browse of the Silent install command field. 

9. Select a batch file that has the execute command and switched required to install the 

legacy image. 

10.Click Save to save the changes that have been made. 

1.15.4 Build the module 

Note: Since this is a hardware specific module based on a legacy image, realistically 

this module can only support one language and one OS. ImageUltra Builder does not 

test the image that is used for the module. It is the responsibility of the individual 

creating the module to insure the source image file is functional and that the language 

and operating systems that are selected for the module are supported by the legacy 

image that was used. 

Tip: The asterisk after the module name in the title bar of the operating system module 

edit window indicates that the module has been modified and not saved yet. 

After all modifications to the module have been completed, the module must be built. The 

following steps show the procedure for building the OS module. 


1. Select the OS module that is ready to be built. See Figure 1-54 

Figure 1-54 IBM ImageUltra Builder - [ThinkVantage: Repository] window 

2. Click the Build button on the menu bar (see Figure 1-54). 

3. A window into the source directory will open. 

4. Select the image file for this module and click Open. Make sure you do not have any 

additional image files in this folder. 

Figure 1-55 Build confirmation window 

5. Click OK. 

Figure 1-56 Build completion window 

6. Click OK. 

Now that the module is built, it can be deployed using one of the methods described in 1.20.4, 

“Deployment methods” on page 88. 

This same process will be repeated for each of the legacy images that your company will be 

deploying using ImageUltra Builder. 


Figure 1-57 Hardware Specific OS modules 

Note: Ensure that the server on which the ImageUltra Builder repository resides has 

sufficient space to contain all of the modules. The hardware specific OS modules will be 

slightly larger than the original legacy images that they were created from since they 

contain the legacy image. 

1.16 Create a base operating system Portable Sysprep Image 

In summary, the characteristics associated with a Portable-Sysprep Image method using 

ImageUltra Builder and Symantec DeployCenter are: 

► Semi-modular (supports the installation of separate application modules and driver 

modules to append the base OS image. 

► Setup is run once on a source computer 

► Sysprep cleans out user information and some hardware-specific information from the 

registry 

► Performs a limited hardware query at the target computer (Windows plug-n-play) 

► User information can be predefined 

The benefits of the ImageUltra Builder and Symantec DeployCenter method are: 

► Initial setup at the target computer is typically 10 minutes or less for a base OS image, 

plus the time it takes to install all application modules 

► Portability of applications and device drivers (such as video, audio, network, etc.) 

► Supports IBM and non-IBM computers 

► Base operating system module can include service packs and large core applications 

(such as office suites), which speeds installation time 


There are five main steps to creating a base operating system module based on a 

portable-sysprep image: 

1. Make the IBM Customization Program accessible to the source computer 

2. Create the portable-sysprep image on a source computer and create the image files 

3. Add the portable-sysprep image to the ImageUltra Builder Repository 

4. Setting the module attributes 

5. Building the module from the image files 

1.16.1 Installing the IBM Customization Program 

Before you can create a portable-sysprep image, you must first make the IBM Customization 

Program (IBMCP.EXE) accessible to the source computer. The ImageUltra Builder program 

enables you to copy the IBM Customization Program on a diskette, shared drive, or any other 

media to which the ImageUltra console has direct-write access. 

1. Use Windows Explorer or My Computer to open the IBMCP folder in your repository. 

Tip: If you cannot remember the path to your repository, in the ImageUltra Builder Main 

window, click File and then click Open repository. The repository paths will be listed. 

You can use any repository. 

2. Copy the IBMCP.EXE program to a diskette or to a shared drive that the source computer 

can access during the development of the image. If you use a diskette, label the diskette 

ImageUltra IBM Customization Program. 

3. Do one of the following: 

a. Provide an ImageUltra IBM Customization Program diskette to any personnel 

responsible for creating portable-sysprep images 

b. Provide the path to the IBMCP.EXE program to any personnel responsible for creating 

portable-sysprep images. 

1.16.2 Create the portable-sysprep image on a source computer 

Before you begin, make sure you put the IBM Customization Program either on portable 

media that is compatible with the source computer or a shared drive that the source computer 

is able to access after the operating system and other programs have been installed. See 

1.16.1, “Installing the IBM Customization Program” on page 55” for more information. 

To create and prepare portable-sysprep image source files, do the following: 

1. On a source computer, use MS-DOS to format the hard disk as follows. 

Note: You must use an MS-DOS diskette for this step. Do not use Windows or PC-DOS 

to partition or format the hard disk. You can create an MS-DOS diskette from Windows 

98, but be sure to also copy the FORMAT.COM and FDISK.EXE programs on the 

diskette. 

Insert the MS-DOS diskette into the source computer diskette drive and restart the 

computer. 

2. Run FDISK.EXE and create a FAT32 primary partition. In most cases, you will want to use 

the entire hard disk except for the service partition. 


3. Leave the MS-DOS diskette in the drive and restart the computer. 

4. Format the primary partition using FORMAT C: /S 

5. Install the Windows operating system (Windows XP or Windows 2000) that you want on 

your target computers. Do not allow the Windows installation program to reformat the hard 

disk. 

6. Access and run the IBM Customization Program (IBMCP.EXE). This program might be on 

portable media or a shared drive. 

7. Sysprep preparation: 

For Windows 2000: 

– Obtain the Microsoft Sysprep program designed for your operating system.The 

Windows 2000 version of the Sysprep program is available from the Microsoft Web site 

at: 

http://www.microsoft.com/windows2000/downloads/tools/sysprep/license.asp 

– You will need the following files: SYSPREP.EXE and SETUPCL.EXE. 

– Copy the SYSPREP.EXE and SETUPCL.EXE files into the C:\SYSPREP folder. 

– If you are creating a Windows 2000 image, obtain the SHUTDOWN.EXE file from one of the 

following sources and copy it into the C:\IBMWORK folder: 

Windows NT® 4.0 Resource Kit Support Tools at: 

http://www.microsoft.com/ntserver/nts/downloads/recommended/ntkit/default.asp 

Windows 2000 Resource Kit at: 

http://www.microsoft.com/windows2000/techinfo/reskit/default.asp 

For Windows XP 

– Obtain the Microsoft Sysprep program designed for your operating system.The 

Windows XP version of the Sysprep program is available from the Microsoft Web site 

at: 

http://www.microsoft.com 

Or on the Windows XP CD in the \SUPPORT\TOOLS\DEPLOY.CAB file. You will need 

the following files: SYSPREP.EXE, SETUPCL.EXE, and FACTORY.EXE. 

– Copy the SYSPREP.EXE, SETUPCL.EXE, and FACTORY.EXE files into the C:\SYSPREP 

folder. 

8. The IBM Customization Program creates an empty TAG file for Windows 2000 

(C:\IBMWORK\WIN2000) and Windows XP Professional (C:\IBMWORK\XPPRO). If you 

are making a Windows XP Home image, rename C:\IBMWORK\XPPRO to 

C:\IBMWORK\XPHOME. 

9. If necessary, install any application that will be common across all of your target 

computers. If you have applications that you cannot make into a module, now may be a 

good time to install them. These application will then become part of your base operating 

system module. 

Note: This step is optional. You can include common applications as part of your 

operating-system module or you can build separate application modules and control 

them through your base map. 

10.Make any other modifications to the image that you feel are necessary for your custom 

installation. 

11.To automate Sysprep do the following: 


– Edit the C:\IBMWORK\PRODKEYP.FM file to include your Windows Product ID key. 

You will need to edit all three lines; 

– You will also need to enter information into the USER SETTINGS of your Base Map. 

Please refer to “Create your base map” on page 66 

12.Use the following procedure to modify the BOOT.INI file so by default, the source computer 

will boot to DOS instead of Windows: 

a. From the Windows desktop, right-click My Computer and then click Properties. 

b. Click the Advanced tab. 

c. Click the Startup and Recovery button. 

d. In the Default Operating System field, use the drop-down menu to select either DOS or 

Microsoft Windows, whichever is present. 

Do not select Microsoft Windows 2000 Professional/fastdetect, Microsoft 

Windows XP Professional/fastdetect, or Microsoft Windows XP Home/fastdetect. 

e. Click OK. 

13.Run SYSPREP.EXE as follows: 

a. Windows 2000: Run C:\SYSPREP\SYSPREP -quiet 

b. Windows XP: Run C:\SYSPREP\SYSPREP.EXE -factory -quiet 

Important: For Windows XP, it is mandatory to run the -factory -quiet command. 

14.Use either Symantec Ghost or Symantec DeployCenter software to create the image files. 

If you intend to deploy the image using CDs, make sure you use the tools provided with 

Ghost and Symantec DeployCenter to segment the image into files that can fit on CDs. 

15.Store the image file in its own folder. In the case of CD deployment, where you have to 

segment the image into CD-sized files, store all of the files in a single folder. Make sure the 

folder is in a location that is accessible to the ImageUltra Builder console. 

16.Store the following files used to create the image (in our example we used Symantec 

DeployCenter) in the same folder as the image file. 

– PQIMGCTR.EXE, PQIMGCTR.OVL PQDPLCTR.RTC 

– Store any batch files or script files you may have created in the same folder as the 

image file. 

1.16.3 Add the donor image to the ImageUltra Builder Repository 

Complete the following instructions to insert the module: 



2. Select the repository. The location that the modules are placed in is not critical. The 

modules can be moved around and reorganized within the same repository just like files in 

a folder in Windows Explorer. 

3. Click Insert. You will see a window similar to Figure 1-58. 

Figure 1-58 Insert Operating System 

Note: When creating your image be sure to: 

1. Store the image file, example T41WXP.PQI, in its own folder. Example: 

c:\Server\Images\T41WXP.PQI 

2. Store the following ImageCenter files in the in the same folder as the image file. 

– PQIMGCTR.EXE, PQIMGCTR.OVL, PQDPLCTR.RTC 

3. Store any batch files or script files you may have created in the same folder as the 

image file 

4. Make sure this folder is in a location that is accessible by the ImageUltra Builder 

console. 

5. Any additional image files will be copied into this module. 

6. Make sure only the above files are stored in this folder. 

4. Click Operating System. 


6. Select Operating System. 


8. Type a name for this Operating System. For example, type: 

IBM T41 Windows XP Pro 



Figure 1-59 Portable Sysprep OS module 


Figure 1-60 OS module type window 

11.Select Base operating system module. 

12.Select Portable Sysprep from the Image Type pull-down menu. 




1.16.4 Setting the module attributes 

Complete the following instructions to set the portable sysprep OS module attributes. 

1. The Operating System module that was just created will open for editing. If it does not, 

double-click the operating system module located in the right window of the ImageUltra 


Figure 1-61 OS module general window 

2. From the General tab, provide a version number for the newly created module. If this is the 

first version of this particular module, use 1.0.0. 

3. In the Comments box, add text that details what this module is for. The operating system, 

hardware platform, business unit, language, date, who created the original image and who 

created the module for the image would all be useful information to include here. 


4. Click the OS/Language tab. 

Figure 1-62 OS/Language window 

5. Select the languages and operating systems that this OS module supports. For our 

example, we selected English and Window XP Professional 

6. Click the Source tab 

Figure 1-63 Enter source parameters 

7. Click Browse of the Source directory field and then select DeployCenter image file that 

will be deployed using this module. 


8. Click Browse add select the executable for your imaging tool. In this example we selected 

the Symantec DeployCenter executable. 

9. Enter the command and switches required to install this image. 

10.Click Save to save the changes that have been made. 

1.16.5 Build the module from the image files 

After all modifications to the module have been completed, the module must be built. The 

following steps show the procedure for building the OS module. 

1. Select the OS module that is ready to be built. 

Figure 1-64 Select the operating system module you wish to build 

2. Click Build from the toolbar. 

3. A window will open pointing to your source directory. 

4. Select the image file for this module and click Open (see Figure 1-65). 

Figure 1-65 image file selection window 

5. Click OK. 


Now that the module is built, it can be deployed using one of the methods described in 1.20.4, 

“Deployment methods” on page 88. 

1.17 Customize an Ultra-Portable operating system module 

Ultra-portable modules are only available by importing them from an existing IBM Preload. 

There are several ways to import an Ultra-Portable module. Please refer to “Import IBM 

Preload modules into your repository” on page 22, for methods of importing modules into an 

ImageUltra Repository 

Ultra-portable images are the most flexible for adapting to various hardware and software 

environments. Since ultra-portable images are only available through the use of existing 

operating system modules, customizations using additional ImageUltra Builder modules may 

be required. This section will illustrate the requirements for changing these files using 

additional modules to customize an image. 

This example outlines the customization of the UNATTEND.TXT file. 

Things you will need are: 

► UNATTEND.TXT - Extract a copy from an existing IBM image. The files are located in the 

c:\i386 directory. 

► A working base map - Modify an existing base map to include this enhancement. 

Note: Refer to 1.13, “Creating an operating system add-on module” on page 39 for details 

on creating this type of module. 

Perform the following steps: 

1. Create the C:\UNATTEND directory. 

2. Copy your customized UNATTEND.TXT into that directory. 

The UNATTEND.TXT below has the information which disables games and components 

not required. 

3. Create an operating system add-on module with the following attributes: 


– Under the General tab in the Name field, type UNATTEND.TXT modification (see 

Figure 1-66). 

Figure 1-66 General Settings for UNATTEND.TXT modification 


Figure 1-67 Source tab window 

– In Figure 1-67 under the Source tab in the Source directory field, type c:\unattend. 


Figure 1-68 Identify File Destination 

– In Figure 1-68 under the Target partition field, select C:. 

– In the Path to copy installable files, type i386. 

4. Select the appropriate languages and operating system. In this example, this means all 

languages and Windows 2000. 

5. Build the module. 

6. Add it to your base map. It should look like Figure 1-69 when complete. 

Figure 1-69 Adding the new module to a base map. 

1.18 Create your base map 

Base maps control which operating systems, applications, and utilities are deployed as part of 

a Smart Image as well as the menu system seen at the target computer during installation. 


The tree structure of a base map varies depending on the type of image or images contained 

in the map and the specific needs of your organization. In any case, you must create a map 

entry in the repository before you construct the map tree structure. 

Driver maps control which device drivers and hardware-specific applications are deployed as 

part of a Smart Image. Driver maps can be simple (specific to one machine type) or complex 

(designed for many machine types), depending on the needs of your organization. 

In this example below we created an ImageUltra Builder Smart Image for Company TVT. It 

includes a base map and a driver map. The base map includes the two portable-sysprep 

donor images.The driver map supports multiple hardware platforms, in our example we 

created driver maps for ThinkCentre and ThinkPad. 

In this section, we will create a base map. Complete the following instructions: 

1. Go to the Base Maps tab (Figure 1-70). 

Figure 1-70 ThinkVantage: Repository 

2. Right-click in the window on the right and select Insert →Base Map. You will see a 

window similar to Figure 1-71. 

Figure 1-71 New Map Wizard window 


3. Click Next to proceed to the Create Map window (Figure 1-72). 

Figure 1-72 Create Map window 

4. Select Base Map and click Next. 

5. In the Name field, type TVT Map. 





7. It is not necessary to copy an existing map for our example, therefore, click Next. 

8. You will see a window similar to Figure 1-75. 


Network synchronization: The network-sync feature enables target computers to search 

for updated maps in the server repository. If a base map has been modified, with the 

addition on a new service pack module for example, the news modules will be injected into 

the service partition of the target computer. 

We do not want to enable synchronization for this example. 




To control the module behavior after deployment, you can select one of the following: 

– Delete none: If after installation you want the service partition of the target computer to 

contain the complete Smart Image, click the Delete none radio button. 

– Delete unused: If after installation you want service partition of the target computer to 

contain only the maps and modules required to recreate the installed image, click the 

Delete unused radio button. 

– Delete all: If after installation you do not want any maps or modules in the service 

partition of the target computer, click the Delete all radio button. 

For our example, we select Delete none. 




11.Click Finish. You will now see the map under the Base Maps tab (Figure 1-78). 

Figure 1-78 ThinkVantage: Repository window 


12.Next, we will insert a menu item into the created map. Right-click in the window pane on 

the right. See Figure 1-79. 

Figure 1-79 TVT Map: Base Map window 

13.Select Insert →Menu item. You will see a window similar to Figure 1-80. 


14.Type English in the box to name the menu item. 

15.Next, select English in the left window and right-click in the window on the right, then 

select Insert →Menu Item. 

16.Type Windows 2000 in the box to name the Menu Item. 

17.Repeat Step 15 to add another Menu Item under the English item. 

We will name this item: Windows XP. 



18.Select Windows 2000 on the left and right-click in the window on the right, then select 

Insert →Operating System. 

The Add Operating System window will appear (Figure 1-82). 

Figure 1-82 Add Operating Systems window 

19.Select Operating System container (Ultra Portable WIN2000) from the list and click 

OK. 

Note: Our example repository contains both modules that have been imported from an 

IBM Recovery CD and the ones we created in 1.13, “Creating an operating system 

add-on module” on page 39. 


20.Repeat Step 18 to insert another operating system module. 

Figure 1-83 Add Operating Systems window 

21.Select Windows 2000 Service Pack 4 from the list and click OK. 

22.Select Windows 2000 on the left and right-click in the window on the right, then select 

Insert →Application. 

The Add Applications window will appear. 

Figure 1-84 Add Application window 

23.Select WinRAR from the list and click OK. 

24.Select Windows 2000 on the left and right-click in the window on the right, select 

Insert →Device Driver. 

The Add Device Drivers window appears. 


Figure 1-85 Add Device Drivers window 

25.Select SoundMAX Audio Driver from the list and click OK. You will see a window similar 

to Figure 1-86. 


1.18.1 Base map settings 

In the Map settings window for a base map, you will see eight tabs (see Figure 1-87). 


Figure 1-87 Map settings window 

General tab 

The General tab lets you view the name and add comments about the map. You can also 

assign keywords, which are used in conjunction with deployment media (ImageUltra Builder 

deployment CDs or diskettes) to minimize the number of maps that can be selected during 

the deployment phase. 

When the diskette or CD is started in a target computer, only those maps with matching 

keywords can be selected. 

User Information tab 

The User Information tab enables you to work with end-user settings that are required 

during the installation process. 

These are typically the settings that you are prompted for during Windows setup or Sysprep 

mini-setup. They include: 

► Administrator password 

► Computer name 

► DHCP configuration 

► User’s full name 

► Gateway 

► IP address 

► Workgroup 


► Organization name 

► Subnet mask 

Important: If you wish to automate your portable-sysprep installation, you must enter a 

value by default. Make sure you do not select the option to prompt the user. 

► Administrator password 

► Computer Name 

► Full Name 

► Workgroup 

You can use the User Information tab to predefine default values, create custom prompts for 

the installer, or both. All defined user information is then presented to the installer near the 

beginning of the installation process, thereby minimizing the amount of time that an installer 

needs to be present during the installation process. 

You can use this tab for base maps for ultra-portable and portable-sysprep images. 

Hardware-specific images do not have the capability of using the information on this tab and 

will ignore any user information defined on this tab. 

Figure 1-88 User Information 

Before/After Menu Options tab 

The Before/After Menu Options tab enables you to execute one or more utilities before or 

after the installation process at the target computer. 

Using the Before/After Menu Options tab is optional. However, it may be helpful for certain 

tasks. For example, you may want to run FDISK to format and re-partition the target computer 

before making selections from the installation menus. 


Figure 1-89 Before/ After menu options 

Install Sequence tab 

The Install Sequence tab enables you to define the order in which modules within the same 

install slot are installed. 

Changing the order of module installation is optional. Usually, there is no need to change the 

module-installation order unless one or more of the following conditions exist: 

► One or more modules have dependencies on other modules being installed first 

► The image is not installing correctly 

► You are installing a base-partition module 

► You have modules that are colliding 

Image Cleanup tab 

The Image Cleanup tab determines which files will be stored in the service partition of the 

target computer after the image has been installed. The choices are as follows: 

► Delete none: If after installation you want the service partition of the target computer to 

contain the complete Smart Image. 

► Delete unused: If after installation you want service partition of the target computer to 

contain only the maps and modules required to recreate the installed image. 

► Delete all: If after installation you do not want any maps or modules in the service partition 

of the target computer. 


Figure 1-90 Image Cleanup settings 

Network Options tab 

The Network Options tab is used to specify network-sync enablement and the method of 

installation. The following is a listing of the fields on the Network Options tab: 

► Use Network Sync: This check box enables you to update maps on target computers that 

have gone through deployment, but have not gone through the installation process. If you 

want the target computer to perform a network-sync operation (check for updated maps 

and modules over a network before installation) select the Use Network Sync check box. 

► Direct-network install: This area enables you to choose how you want the Smart Image 

to be installed. 

Important: You will need DHCP services running on your repository server to use this 

method. 

► The following describes the available selections: 

– Yes: Click this radio button to configure the map for a direct-network installation. A 

direct-network installation deploys and installs the image directly over the network. The 

target computer requires a network connection throughout the entire process. 

– No: Click this radio button to configure the map for a standard deployment with local 

installation. This option deploys the Smart Image to the service partition of the target 

computer either over the network or from an ImageUltra Builder distribution CD and the 

installation takes place locally without any dependencies on a network connection. 


– Prompt the user when the image is deployed: Click this radio button to prompt the 

person at the target computer to select the method of deployment and installation as 

soon as the map has been selected. 

Figure 1-91 Network Options 

Menu Appearance tab 

The Menu Appearance tab provides various choices that enable you to customize the 

appearance of the menus that are seen on the target computer during the installation 

process. 

► Color settings: This field enables you to customize the color of certain menu components 

seen during the installation process. The Item drop-down box enables you to select 

different aspects of the menu while the Color drop-down menu enables you to select which 

color you prefer. 

► Layout settings: This field enables you to customize how menu information is presented 

during the installation process. 

► Keyboard settings: This field enables you to customize some keyboard functions during 

the installation process. You can select following options: 

– Previous menu key: Use the drop-down menu in this field to program which key 

enables the person performing the installation to navigate from the current menu entry 

to the previous menu entry. 

– Exit menu key: Use the drop-down menu in this field to program which key enables 

the person performing the installation to exit the menu selection process. 

– System menu keyword: If your map has a menu item that is set as a system menu, 

then text entered in this field will automatically take you to the hidden menu item. For 


example, if you type the word system_menu in this field, the word system_menu can 

be typed during the installation process. Then, the system_menu opens. 

– Enable Ctrl-Alt-Del: Select this check box to enable the person performing the 

installation to use Ctrl-Alt-Del during the menu selection process. 

Partition tab 

The Partition tab enables you to define a custom size for the service partition. A custom 

service-partition size enables you to leave room for other products that share the service 

partition, such as the Rescue and Recovery program. By making allowances for extra space, 

you can substantially reduce the installation time normally required by these programs to 

resize existing partitions. 

Figure 1-92 Base map partition settings 

1.19 Create a driver map 

There are some fundamental differences between base maps and driver maps. Unlike for 

base maps, the only components that are added to a driver map are menu items and device 

driver modules. Menu items in driver maps have no effect on the menus displayed at the 

target computer. The only purposes for menu items in a driver map are: 

► To provide the developer with a mechanism for annotation 

► To assign filters to one or more device driver modules 


It is not always necessary to include a driver map as part of a deployable Smart Image. If you 

deploy an ultra-portable image or a portable-sysprep image to an IBM HIIT enabled target 

computer, you have the choice of: 

► Using a driver map and managing all of the device driver modules required for the target 

computer. 

► Not using a driver map and relying on the IBM provided device driver modules in the 

service partition or HPA of the target computer. 

If you deploy a hardware-specific image to a target computer, any driver map deployed as 

part of that Smart Image will be ignored during the installation. The target computer requires 

all device drivers to be included in the hardware-specific image. 

Tip: It may be a good idea to work with two driver maps in your Repository. One driver map 

for production and one for testing. 

1.19.1 Driver Map settings 

You can view or modify the settings associated with a map by doing the following: 

1. Open the map from the Repository window 

2. Right-click anywhere in the right pane and select Settings. The settings dialog differs 

depending on whether the map is a base map or driver map. 

In the Map settings window for a driver map, you will see only two tabs: 

Figure 1-93 Driver Map settings window 

► The General tab is the same as for the base map. 

► The Network Options tab has one setting that is different from the Base Map settings: 


Use driver map filter processing: Driver-map filter processing determines which 

device-driver modules get deployed to the target computer. When Driver-map filter 

processing is enabled (a check in the check box), only those device-driver modules that 

match the filter requirements are deployed as part of the Smart Image. When Driver-map 

filter processing is disabled (the check box is empty), all device-driver modules defined in 

the driver map are deployed as part of the Smart Image. 

It may be a good idea when constructing Driver Maps to have one map for testing and one for 

production. 

For conceptual information about constructing the driver-map tree structure, see ImageUltra 

Builder Version 2.0 User Guide. 

1.20 Deploying images using ImageUltra Builder 

Corporations can have multiple methods and requirements for deploying images. Scenarios 

may include network deployment, CD media or an integration center such as the IBM Imaging 

Technology Center. Only one method may be required, all methods or a combination of 

several. It can be extremely labor intensive to try to maintain, update and deploy these 

images every time a change is required. ImageUltra Builder can help simplify and streamline 

this process. 

The Deploy selection within ImageUltra Builder opens the Deploy Wizard. The Deploy Wizard 

prompts you through the steps required to create a Network Deployment Diskette, or 

stand-alone Distribution CDs. The deployment diskette establishes a connection to the 

repository, provide an interface for selecting the desired maps, and deploy the appropriate 

maps and modules to the appropriate staging area (service partition, HPA, or network-staging 

folder). The stand-alone Distribution CDs contain all of the required maps and modules to 

deploy them to the target computer without using a network. A repository window must be 

open before this selection can be made. 

1.20.1 Creating an ImageUltra Builder boot diskette 

To create a standard ImageUltra Builder network boot floppy for network or CD distribution: 

1. Open the repository from where you will deploy. 


2. Click the Deploy button or click Tools →Deploy. You will see a window similar to 

Figure 1-94. 

Figure 1-94 ImageUltra Deploy Wizard Main window 

3. Select your deployment method, network or from CD and click Next. 

4. Select Yes I want to create my “ImageUltra deployment diskette” now and click Next. 

All data on the disk will be overwritten in the next step. 

5. Click the Create Diskette button to make the boot floppy. 


6. The date will be written to the diskette, select Yes or No to create additional copies and 

click Next. You will see a window similar to Figure 1-95. 

Figure 1-95 Deploy Network Settings window 

Depending on whether you chose to deploy via the network or CD, follow these steps: 

Via the network: 

1. In the appropriate fields, enter your specific information, if applicable. 

– Location of the repository 

– Connect As: 

User name 

Password (if required) 

– TCP/IP address of the Server 

– Locale 

– Language and keyboard layout 

– Keywords (allows only those maps with matching keywords to be selected from the 

repository) 

2. Click the Read button to review the current settings on the floppy disk, Click the Write 

button if you edited the settings. 

3. Click Next and Finish. 

Via CD distribution: 

1. Select the base map and driver map you wish to deploy and click Next. 


Figure 1-96 Deploy CD Map Locations 

2. Specify a directory to copy the CD layout files to and click Next. The subdirectories will be 

named in sequence CD1, CD2, CD3, etc. You will then copy the corresponding contents of 

the subdirectories to your CDs using your CD creation software. 

3. Select a CD size and click Create Image. 

4. Click OK at the CDs were created successfully window and click Next. 

Important: Do not click the Back Button at this point or you will have to complete the 

Create Image step again. 

5. View the location of the Smart Image and click Next. 

6. Click Finish to exit. 

1.20.2 Creating a bootable Network Deployment CD from a diskette 

To speed up booting to the server, you could create a network boot CD instead of using your 

floppy disk: 

► Create a Network Deployment Diskette as in 1.20.1, “Creating an ImageUltra Builder boot 

diskette” on page 83. 

► Use the CDRW software of your choice to create a bootable CD. 

► Copy all the files from the diskette to the CD. 

1.20.3 Creating a custom network boot diskette 

In this section, we will create a network boot diskette without using the ImageUltra process. 


Adding new DOS network drivers to the deployment diskette 

Create an ImageUltra Builder network driver package (.PCI file) as follows: 

1. Download the DOS driver files for the new network card. These files usually have a .DOS 

file extension (only NDIS drivers are supported). 

2. Create a PROTOCOL.INI file that will correctly load the driver and the TCP/IP protocol. 

3. Create a PCI.TXT file that lists all of the PCI vendor and device IDs for the network cards 

for which this driver applies. 

4. Create an INSTALL.BAT file to copy all of the necessary driver files into the 

%NETROOT%\CLIENT folder. 

5. Create a LOADNIC.BAT file to load whatever device drivers are required to load the 

network driver. 

Note: You probably will need to use the DYNALOAD command in the LOADNIC.BAT file. 

Most DOS drivers are loaded through the CONFIG.SYS file. DYNALOAD allows the driver 

to load later in the boot process as required by the ImageUltra Builder program. If the 

DYNALOAD command fails to load the .DOS driver, you will have to create your own 

deployment diskette. 

6. Create a REMOVE.BAT file to delete the driver files from the %NETROOT%\CLIENT 

directory. 

7. Compress all of the file into a ZIP file; then change the .ZIP extension to .PCI. 

8. Create the Network Deployment Diskette image from the ImageUltra Builder interface as 

usual (see the ImageUltra Help system for details). 

9. Copy your new .PCI file into the \IBMNET\DRIVERS folder of the diskette. If there is not 

enough room on the diskette to accommodate the new .PCI file, delete one of the old .PCI 

files that you do not use from the diskette. 

When you boot the updated Network Deployment Diskette, it will process all of the .PCI 

files in the \IBMNET\DRIVERS folder and detect the correct network card. 

Creating your own Network Deployment Diskette 

If you have a DOS boot diskette that already connects to the network for your environment, 

you can use this diskette to deploy images instead of using the Network Deployment Diskette 

created through the ImageUltra Builder program. 

However, there are a few requirements that your diskette must meet before you can use it: 

► Your diskette must create a RAM Drive with at least 10 MB of free space 

► The Repository Tools folder must be included in the path 

► The initial environment must be set to a minimum of 1024 bytes and the following 

environment variables must be set: 

– RAMD=R: {the drive letter of the RAM drive} 

– IUDRIVE=X: {the drive letter of the Repository drive} 

– IUREPOS=Data\Files\Repos: {the directory of the Repository path} 

Once your DOS diskette meets these requirements, boot your DOS diskette and connect to 

the Repository. Then, run DEPLOY.BAT to begin the ImageUltra deployment process. 


1.20.4 Deployment methods 

In this section, we exercise the deployment methods. 

Tip: IBM Imaging Technology Center (IITC) can preload your workstations with your 

custom ImageUltra Builder configuration. This can enable immediate installation of a 

workstation without requirements for media or network connections. For more information 

on the IITC please refer to their web site. 

http://www.pc.ibm.com/cbcc/cbccweb.nsf/Home 

CD distribution 

Direct deployment from Distribution CDs involves copying all modules defined in the selected 

base map and driver map to a set of CD-R or CD-RW discs. The first disc of the set is 

bootable. When started in the target computer, the CD copies the modules from the CDs to 

the service partition of the target computer and prepares the target computer for the 

installation process. If a service partition does not exist at the start of the deployment 

process, one is created. 

Use the ImageUltra Builder Deploy Wizard to create a set of stand-alone Distribution CDs. 

Based on your responses, the Deploy Wizard prompts you through the steps required to 

create the CDs. 

Typical steps include the following: 

► Creating a Network Deployment Diskette 

► Selecting the base map and driver map to be used 

► Selecting the location where the CD files are to be stored 

After all required questions have been answered, the Deploy Wizard creates individual folders 

for each CD in the location specified. You can then use the CD-RW software of choice to 

create the CDs. Because CD 1 must be bootable, and uses specific files from the Network 

Deployment Diskette, make sure you follow the instructions provided by the Deploy Wizard 

and the ImageUltra Builder help system for creating CDs for CD deployment. 

Figure 1-97 shows the deployment process using an ImageUltra Builder Distribution CD and 

a local installation process, which uses a service partition as a staging area. 


Modules 

Maps 

Repository 

1 

Figure 1-97 CD deployment 

Deployment Installation 

2 

3 

Copy 

Create 

distribution Start target 

CD computer with 

distribution CD 

Smart image 

on staging area 

(service partition) 

Base Map 

Driver Map 

Modules 

Unused 

Make menu 

selections to 

define the 

image to be 

installed 

Base Map 

Driver Map 

Modules 

Unpacked 

Modules 

C Partition 

Base Map 

Driver Map 

Modules 

OS 

Apps 

Drivers 

Unpack 

Smart image 

on dervice 

partition 

Final image 

on C partition 

1. The first step in CD deployment is the creation of a set of ImageUltra Builder Distribution 

CDs, which is described above (for more information, see the ImageUltra Builder help 

system). 

The person controlling the deployment starts the process by booting the target computer 

with an ImageUltra Builder Distribution CD. 

2. The maps and modules contained on the set of CDs are copied to the service partition, 

which acts as the staging area for the complete Smart Image. 

Note: At this point, a message is displayed stating that the deployment phase is 

complete. The person controlling the deployment can either shut down the computer at 

this point and ship it to another location, or continue with the installation phase. 

3. The person controlling the installation process starts the installation phase by making 

selections from the installation menus to define the image to be installed. 

4. The modules required for the defined image are unpacked from the service partition onto 

the C partition. 

5. The setup process begins. When the installation phase is over, the C partition contains the 

new image and the service partition contains the Smart Image, which can be used for 

client-side recovery. 

Note: An optional cleanup step can be defined in the base map Map Settings window to 

minimize the size of the service partition and keep only those files required for the installed 

image, or eliminate the service partition. 

4 

Setup 

Chapter 1. ImageUltra Builder 89 

6 

5

Network deployment 

This method uses a bootable, DOS-based diskette or CD to establish a network connection 

between the target computer and the ImageUltra Builder module repository. Once the 

connection is established, you select which base map and driver map to use. Depending on 

your base-map settings, one of the following occurs: 

► If you specified a direct network installation, a temporary network-staging folder is 

created on the network specifically for the target computer. The maps are copied to this 

folder and all modules that control the installation procedure are unpacked to this folder. 

When the installation process begins, the hard disk is prepared and all modules required 

for the image content are obtained from the repository and unpacked dynamically as they 

are needed. A direct-network installation requires a network connection throughout the 

deployment and installation process. 

► If you specified a network deployment with local installation, all of the modules defined 

in the map are downloaded to the service partition of the target computer, and the target 

computer is prepared for the installation process. If a service partition does not exist at the 

start of the deployment process, one is created (for more information about service 

partitions, see the ImageUltra Builder Version 2.0 User Guide). 

For direct network deployment (network deployment with local installation), you use the 

ImageUltra Builder Deploy Wizard to create either an ImageUltra Builder Network 

Deployment Diskette or an ImageUltra Builder Network Deployment CD. Based on your 

responses, the Deploy Wizard prompts you through the steps required to create the 

diskette or CD. 

Note: Providing user name and password information on the deployment media (diskette 

or CD) is optional. If you do not provide a user name and password when you create the 

deployment media, the person controlling the deployment process will be prompted for this 

information (if it is required to access the network) when the deployment media is started 

on the target computer. If you do provide a user name and password when you create the 

deployment media, it is stored in a flat text format on the deployment media, not in a secure 

format. 

If you choose to make a CD, create the diskette first, and then use the CD-RW software of 

your choice to create the CD from the diskette. Because this CD is bootable, make sure you 

follow the instructions in the Deploy Wizard or ImageUltra Builder help system for creating a 

Network Deployment CD. Depending on the type of removable-media drive available at the 

target computer, use either the diskette or CD to establish a network connection between the 

target computer and the ImageUltra module repository. After the connection is established, 

select which base map and driver map to use. All of the modules defined in the map are 

downloaded to the service partition or HPA of the target computer, and the target computer is 

prepared for the installation process. If a service partition or HPA does not exist at the start of 

the deployment process, one is created. 

The following illustration shows a direct-network installation, which uses a network-staging 

folder as a staging area. 


Modules 

Maps 

Repository 

Select 

base map 

and driver map 

Figure 1-98 Direct network installation 

Unused 

Staging area 

(Network-staging 

folder) 

Copy (optional) 

Unpack 

1 

2 

Base Map 

3 

Unpack Driver Map 

Unpack 

required 

modules 

Modules 

Make menu 

selections to 

define the 

image to be 

installed 

Setup 

4 

Base Map 

Driver Map 

Modules 

OS 

Apps 

Drivers 

(Optional) 

Smart image 

or copy of 

installed 

image 

Final image 

on C partition 

Complete the following steps: 

1. The person controlling the direct-network installation starts the process by booting the 

target computer with an ImageUltra Builder Deployment CD or ImageUltra Builder 

Deployment diskette, and then selects the required maps from the repository. 

2. A network-staging folder is created specifically for the target computer. The selected maps 

and a limited number of modules (only those required to control the installation process) 

are copied to the network-staging folder, which acts as a staging area for the installation 

process. 

3. The person controlling the direct-network installation makes selections from the 

installation menus to define the image to be installed. 

4. The modules required for the defined image are obtained directly from the repository and 

copied over the network to target computer C partition and the setup process begins. 

5. When setup is complete, the C partition contains the new image. 

Note: Optionally, if a developer of the image specified that a service partition is to be 

created for client-side recovery purposes, the maps and modules are also copied to a 

service partition. 

Network deployment process with local installation 

The following illustration shows the standard network deployment process with local 

installation. Notice that the service partition is used as the staging area for all maps and 

modules required for the Smart Image. 


Modules 

Maps 

Repository 

Figure 1-99 Standard network deployment 

1. The person controlling the deployment starts the process by booting the target computer 

with an ImageUltra Builder Deployment CD or ImageUltra Builder Deployment Diskette, 

and then selecting the required maps from the repository. 

2. The selected maps and all modules defined within the maps are obtained from the 

repository and copied over the network to the service partition, which acts as the staging 

area for the complete Smart Image. 

Note: At this point, a message is displayed stating that the deployment phase is 

complete. The person controlling the deployment can either shut down the computer at 

this point and ship it to another location, or continue with the installation phase. 

3. The person controlling the installation process starts the installation phase by making 

selections from the installation menus to define the image to be installed. 

4. The modules required for the defined image are unpacked from the service partition onto 

the C partition. 

5. The setup process begins. When the installation phase is over, the C partition contains the 

new image and the service partition contains the Smart Image, which can be used for 

client-side recovery. 

Note: An optional cleanup step can be defined in the base map Map Settings window to 

minimize the size of the service partition and keep only those files required for the installed 

image, or eliminate the service partition. 

The advantages of CD deployment are speed and the flexibility of not having to be dependent 

on a network connection. 


Deployment Installation 

1 

Select 

base map 

and driver map 

2 

Copy 

Smart image 

on staging area 

(service partition) 

Base Map 

Driver Map 

Modules 

Unused 

3 

Make menu 

selections to 

define the 

image to be 

installed 

Base Map 

Driver Map 

Modules 

Unpacked 

Modules 

C Partition 

Setup 

Base Map 

Driver Map 

Modules 

OS 

Apps 

Drivers 

5 

Unpack 

4 

Smart image 

on dervice 

partition 

Final image 

on C partition

The advantage of network deployment is the assurance that the latest maps and modules will 

be installed if the network-sync function is enabled. 

With the exception of a direct-network installation, the division between the deployment and 

installation is a single boot cycle. In many cases, deployment is done in one location and 

installation takes place in another location, typically at the end-user’s work area. When 

deployment is complete, you can shut down the target computer and prepare the computer 

for delivery to the end user’s work location for the installation to be completed. 

In our fictitious Acme Holdings Inc. company (see 1.25, “Business case” on page 129), 

multiple deployments will be used. 

► For new PC rollouts, a direct network deployment with local installation method will be 

used by an Integration Center. 

► CD deployment will be used to send images to locations or users without a WAN or 

broadband connection. 

The deployment method is flexible to meet the needs of any business or individual. 

Note: Some large enterprises that use drive-duplication technology for mass production 

might want to replicate the drive at the end of the deployment process, prior to installation. 

In order for this drive-duplication process to work successfully, you must install the IBM 

Boot Manager on each drive after the drive has been duplicated. You can get the IBM Boot 

Manager installation tool (BMGRINST.BAT) from the TOOLS\BMGR folder of your 

repository. You must run BMGRINST.BAT during a DOS session. 

1.21 Using ImageUltra Builder and Symantec DeployCenter 

together 

The following sections include an overview of Symantec DeployCenter, as well as a 

step-by-step guide on how to use this tool with ImageUltra Builder. 

1.21.1 Overview of Symantec DeployCenter 

Symantec DeployCenter Library provides you with proven solutions for system deployment 

and migration. With Symantec DeployCenter Library, you can deploy an exact image of a hard 

disk and deploy the image to multiple workstations. Symantec DeployCenter Library includes 

the following tools for windows deployment and managing image files. 

ImageCenter 

The ImageCenter application uses SmartSector imaging to create an exact image of a hard 

disk or partition. That exact image can then be used to deploy Windows workstations, 

upgrade existing workstations, manage changing desktop environments, and quickly and 

easily back up and restore hard drives. With ImageCenter, you can create and restore a 

compressed image file of an entire hard disk or individual partitions of a hard disk on a local 

drive, across a network, or on a removable media device. 

ImageCenter can be used to clone Windows 2000 and XP for installation on other machines. 

When doing so, you must consider the Security Identifier (SID). Improperly cloning a 

Windows 2000/XP workstation will result in your having another machine with the same SID 

which causes 2000/XP system conflicts. ImageCenter is compatible with Microsoft System 

Preparation Tool (SysPrep) to resolve SID conflicts. 


Image Explorer 

Simplify management of your image files with Image Explorer. Working within a single screen 

gives you total control of the image files you can access. You can view image file contents, 

copy image files, copy partitions within files, restore individual program and data files from the 

image, or add password protection to image files. Image Explorer also provides description 

capabilities, so you can easily identify individual image files and partitions. 

Virtual Boot Environment a.k.a Virtual Floppy 

The Virtual Boot Environment (VBE) allows DOS programs to execute from the hard drive on 

Windows 9X, Me, NT, 2000 and XP platforms as though they were running from a boot floppy. 

The VBE can be sent to a particular system remotely, the system will boot into a temporary 

environment to run tasks such as capturing or restoring an image, and then boot the system 

back into the active operating system state. The benefits of this are there is no need to create 

bootable media and visit each system for new image deployment or updates. 

The Virtual Boot Environment operates by temporarily replacing the Master Boot Record 

(MBR) boot code on the primary hard drive. Upon rebooting the computer, the new boot code 

loads and runs the programs stored in the VBE image file. This VBE consists of a loader 

program, disk I/O redirector TSR program, and a non-compressed floppy boot image file. The 

boot image file is created from a 1.44 MB or 2.88 MB format bootable floppy. It contains both 

the bootable OS files, network drivers and the user application programs just as would exist 

on a bootable floppy disk. 

Upon booting, the VBE loader builds a RAM DRIVE in memory the size of the boot image file, 

copies the boot image file from the hard drive to memory and then loads and executes the 

boot sector within the boot image file. Under DOS, the A: drive is then used to reference the 

boot image file system just like when booting from a CD. The first physical floppy drive is 

accessed as drive letter B:. 

The Virtual Boot Environment image file is a raw sector-by-sector representation of a floppy 

file system in either a 1.44 MB or a 2.88 MB floppy disk format. It contains everything that 

would exist on a bootable floppy disk (boot sector, FATs, directories, and files). 

PowerCasting a.k.a. Multicast 

ImageCenter combines SmartSector imaging technology together with Ethernet or Token 

Ring multicasting to provide a fast and robust method for deploying workstations. 

PowerCasting sends the Symantec DeployCenter Library Image file to one or more 

PowerCast clients simultaneously. The image file is sent only once by the server to all the 

client computers, rather than separately to each client. This decreases network traffic by 

eliminating duplicate restore processes when preparing multiple workstations and when 

performing computer rollouts and migrations. 

The PowerCasting technology in conjunction with VBE is an ideal way to deploy multiple 

systems across your organization. You can include the Symantec DeployCenter Library 

imaging tools and scripts and appropriate network drivers as part of the VBE that allows 

multiple systems to pull an image from a central server. Because this task is performed 

remotely, it eliminates the need to visit the computer and boot using a floppy disk. 

For detailed instructions on using PowerCasting please refer to the whitepaper titled The 

Benefits of using ImageUltra Builder and Symantec DeployCenter Library. 

Unicasting 

The Unicast feature lets you create and restore images using a network drive without 

mapping the drive. It consists of a Unicast server and a Unicast client, which reside on 


separate machines. You can specify all Unicast parameters on the command line of either the 

server or the client. The Unicast operation is a point-to-point and uses the TCP/IP protocol. 

The Unicast server must be started prior to running the Unicast client or before trying to 

PXE-boot a client machine. Once the server has been started, you do not need to tend to it. 

You start all Unicast operations from the client by using a standard script file or the 

ImageCenter interface. 

For detailed instructions on using Unicasting please refer to the whitepaper titled The Benefits 

of using ImageUltra Builder and Symantec DeployCenter Library. 

PXE a.k.a Network Boot 

PXE (Pre-boot Execution Environment), a component of Intel®'s Wfm (Wired for 

Management) specification, allows a computer's PXE-compliant network card to download 

and run a Virtual Boot Environment from the network prior to booting the operating system on 

the hard disk. Because this task is performed remotely, it eliminates the need to visit the 

computer and boot using a bootable floppy or CD. 

1.22 Image development 

This section will give an example on how to: 

► Create your donor image 

► Use PXE and Virtual Boot Environment to capture the donor image. 

► Add the donor image to the ImageUltra Builder repository 

► Create a ImageUltra Builder Smart image using the donor image as a base 

► Clone a single ImageUltra Builder Smart Image 

1.22.1 Create your donor image 

For a detailed explanation of how to create your donor image, please see section on “Create 

and prepare the image file” on page 48. 

1.22.2 Use PXE and Virtual Boot Environment to capture donor image 

To use Symantec DeployCenter Pre-boot Execution Environment (PXE) for capturing the 

donor image you have to: 

1. Confirm that you have installed the PXE services correctly 

2. Confirm you have the correct Network drivers for your clients installed into boot disk 

builder 

3. Create a Virtual Boot Diskette including the correct network driver for your donor system 

4. Add your PXE virtual floppy to the PXE configuration utility 

5. Add a CAPTURE IMAGE selection to the PXE client menu 

6. Capturing the donor image 

Note: You will need to have a DHCP Server installed to use this cloning method. For 

our examples we used Windows 2000 Server. 


1.22.3 Confirm that you have installed the PXE service correctly 

1. Log onto the Windows server 

2. Go to Start → Programs →Administrative Tools 

3. Select DHCP 

4. Locate the Scope Options 

5. Ensure that the option 003 Router is installed 

6. Ensure that the option name 060 ClassID is installed 

Figure 1-100 DHCP scope options 

7. Locate Start →Programs →PowerQuest DeployCenter 5.5 Tools 

8. Ensure that the PXE Configuration Utility is installed 

9. If none of these are available, install the PXE option provided with the DeployCenter 

media. 

1.22.4 Confirm you have the correct Network drivers installed in boot disk 

builder 

The Boot Disk Builder includes many predefined network drivers. In an event that the network 

driver you need for the client is not available you have to add it to the Boot Disk Builder. 

The step-by-step description below will describe how you add your own driver to the Boot 

Disk Builder: 

1. Record client’s network cards VIN identifier 

a. Create a virtual floppy to help detect the VIN identifier 

b. Import the virtual floppy into the PXE utility 

c. Boot the client and record the VIN 

2. Add the client network driver to the Boot Desk Builder 

Record client’s network cards VIN identifier 

Create a virtual floppy to help detect the VIN identifier: 

1. Go to Programs →PowerQuest DeployCenter 5.5 →DeployCenter 5.5 → Tools Boot 

Disk Builder 

2. Select Standalone Boot Disk 


Figure 1-101 Select Standalone Boot Disks 

3. Select Next. 

4. In the Run ImageCenter from section, select Do not Run ImageCenter. 

Figure 1-102 Select option do not run ImageCenter 

5. Select Next. 

6. Select Virtual Boot Disk File. 


7. Add the file name Detect Network Adapter. 

Figure 1-103 Detect Network Adapter 

8. Select Finish Click YES when you are asked to save these settings for future use. 

9. Name the settings file Detect Network Adapter. 

10.Click Save. 

11.Click OK to confirm. You will be asked to save these settings for later use. Say yes and 

save these settings to the following directory: C:\program 

Files\PowerQuest\DeployCenter 5.5\BDBuilder\ 

12.Exit the BOOTDISK BUILDER. 

13.Locate Start →Programs →PowerQuest DeployCenter 5.5 Tools. 

14.Select PowerQuest VF editor. 

15.Select File →Open. 

16.Locate the Detect Network Adapter Boot Disk file (.vfd) you just saved. 

Tip: Look in C:\program Files\PowerQuest\DeployCenter 5.5\BDBuilder for your 

Detect Network Adapter.vfd file. 

17.Select Open 

18.Delete the following files: 

PQDOTASK.BAT 

MOUSE.COM 


Figure 1-104 Delete mouse.com and pqdotask.bat from your boot disk file 

19.Highlight AUTOEXEC.BAT. 

20.Select Extract. Accept the default. Ignore subdirectories. 

21.Select a temporary directory from where the AUTOEXEC.BAT can be edited e.g C:\TEMP. 

22.Click OK to save the file. Do NOT Close the PowerQuest VF Editor Window. 

23.Locate C:\TEMP folder using the Explorer. 

24.Select AUTOEXEC.BAT. 

25.Right-click AUTOEXEC.BAT. 

26.Select Edit. 

27.Delete the line CALL PQDOTASK if it exists. 

28.Add the word kicknic. 

Figure 1-105 Add Kicnic to the AUTOEXEC.BAT file 

29.Save AUTOEXEC.BAT. 

30.Close the Notepad. 

31.Open Windows Explorer. 

32.Locate C:\Program Files\PowerQuest\DeployCenter 5.5\BD Build folder. 

33.Copy KICKNIC.COM into the C:\TEMP directory. 

34.Close the explorer window. 

35.Open up the PowerQuest VF Editor window. 

36.Select Image. 

37.Select Inject. 


38.Locate the C:\TEMP. 

39.And select AUTOEXEC.BAT and KICKNIC.COM. 

40.Select Open. 

41.Confirm that you want to inject the two files into the Virtual Floppy. 

42.Answer Yes to replace AUTOEXEC.BAT. 

43.Save and close the PowerQuest VF Editor. 

Import the Virtual Floppy into the PXE configuration Utility 

1. Open PXE Configuration Utility. 

2. Select Add. 

3. Locate Detect Network Adapter.vfd located in BDBUILD directory. 

4. Highlight and select OPEN. 

5. Select OK to confirm the addition. 

Figure 1-106 Configuration Utility - Detect Network Adapter 

6. Select PXE Client Menu tab. 

7. Select Add. 

8. Type Detect Network Adapter as the menu name. 

9. Select Detect Network Adapter.1 and assign it to virtual floppy. 

Figure 1-107 Add PXE Client - Detect Network Adapter 1 


10.Click OK. 

Figure 1-108 PXE client menu - Detect Network Adapter 

11.Exit the configuration Utility. 

Boot the client to detect the network VIN identifier 

1. Power on the client 

2. Press F12 at boot time to activate the alternative boot menu 

3. Highlight the correct PXE boot agent for the client 

4. example: IBA 4.1.04 Slot 0240 

5. The client will now boot to the DeployCenter PXE server 

6. On the PXE menu select Detect Network Adapter 

7. Press Enter 

8. When the boot is completed you will see the VIN number at the bottom on the client 

screen. Example: PCI\VEN_8086&DEV_1031&REV_42&SUBSYS_02091014 

9. Record that number on a piece of paper. This number will be used to add the correct 

network driver for your client into boot desk builder 

10.Close the PXE Configuration Utility 

Add the correct client network driver to the Boot Disk Builder 

1. Create a share called IMAGES on your server. 

2. Download and extract the latest Network driver for your client and save on to a folder on 

your deployment server. 

3. Open BOOT DISK BUILDER. 

4. Select Microsoft TCP/IP Boot Disk. 


Figure 1-109 Boot Disk Builder - Microsoft TCP/IP Boot Disk 


6. Fill in the User Name and Password to logon to your Server Image share. In our example 

the user is: Admin, and the UNC path to the share is \\server\images with the drive letter 

i: 

Figure 1-110 Boot disk builder - Network Login information 



8. Leave the screen shown in Figure 1-111 as is. 

Figure 1-111 Boot disk builder - run ImageCenter from BOOT DISK 


10.Select Add. 

11.Select Enter Drive Information manually. 

Figure 1-112 Add Network Drivers - Enter driver information manually 

12.Select Next. 

13.Add the VIN Number you recorded earlier. In our example it is: 

PCI\VEN_8086&DEV_1031&REV_42&SUBSYS_02091014 


14.Add the network adapter description. 

Figure 1-113 Add network drivers - Network Adapter ID and description 


16.Locate the network Adapter Driver Files you downloaded and extracted. 

17.Locate the DOS directory. 

18.Select the correct com-file. In our example it is IPXODI.COM. 

19.Click Open. 

20.The driver is now added to the Add network driver screen. 

Figure 1-114 Add network drivers - ipxodi.com 


22.Locate the Microsoft TCP/IP NDIS2DOS driver file. In our example it's a file called 

E100B.DOS. 

23.Click Finish and the network adapter is now added to list of available drivers. 


Figure 1-115 Boot Disk Builder - Select network adapter from list 

24.Click Next 

25.Leave default settings. We will now name the boot disk Capture Image 

Create 

your donor 

a Virtual 

system 

Boot Diskette including the correct network driver for 

1. Open Boot Disk Builder 

2. Select Microsoft TCP/IP Boot Disks 

3. Enter server login information 

4. Click Next 


5. Select Boot Disk and click Next 

Figure 1-116 Select Boot Disk 

6. Click Next 

7. Select the network adapters you need from the list 

8. Select Obtain an IP address from a DHCP server 

Figure 1-117 Boot Disk Builder - Accept Default settings 


9. On the screen shown in Figure 1-118, select Virtual Boot Disk, and name the boot disk 

CAPTURE IMAGE. 

Figure 1-118 Boot Disk Builder - Select virtual boot disk file 

10.Click Finish 

11.Select Yes when asked to save this for future settings 

12.Save these settings as Capture Image.vfd 

13.Select OK to confirm saving 

14.Select Exit to close the Boot Disk Builder 

1.22.5 Add the CAPTURE IMAGE.VFD to the Configuration Utility 

1. Open the PXE Configuration Utility 

2. Click the PXE Virtual Floppies Tab 

3. Click Add →Browse →Software →Intel driver →Capture Image.vfd 

1.22.6 Add CAPTURE IMAGE selection to the PXE Client menu 

1. Click the PXE client menu tab 

2. Click Add →Type in CAPTURE IMAGE as the menu name 

3. Select Capture Image 1 from list. 

4. Click Save →OK →Exit. 

5. We have now configured the DeployCenter PXE support to be able to manually capture an 

image of the ImageUltra Builder Donor system and save it onto the server shared image 

drive (I:). 


1.22.7 Capturing the donor image 

Once you have prepared the donor system to be imaged, use the instruction below to create 

a donor image on the server. 

1. Connect the donor system to the server. 

2. Power on the donor system. 

3. When you see the IBM image, pressing F12 the alternative boot menu. 

4. Select the PXE boot option. 

In our example we use the IBA 4.0.22 Slot 0240. 

5. Press Enter. 

6. When you see 'Please select from the following items:' select Capture Image by using the 

tab key. 

7. Press Enter. 

8. After a few second you will see the ImageCenter main menu screen. 

9. Click Create Image. 

10.Press Enter. 

11.Type the name of your image file in the Image File:. Use the complete path and image file 

name. In our example we used H:\IUBWXP.PQI 

12.Add a description of the donor image you are creating in the Image File Comments: field. 

This is version 1.1 that contains Windows XP Portable Sysprep image with the following 

changes, Updated MassStorage list in sysprep.inf. 

13.Use the tab key to select Next. 

14.On the Compress Image File screen, select High Compression. 

15.Select Next. 

16.The next screen contains the details of your donor image, hard drive size and image file to 

be saved and level of compression used. 

17.Review the option under the Advanced Options button. 

18.When you have reviewed all setting, click Finish. 

19.ImageCenter will now start cloning your client image and store it as a donor image onto 

your network share. 

20.When image capture is complete you will see a confirmation screen. Review the screen 

and confirm there where no errors during the image creation. 

21.Close the ImageCenter 

22.Power off the client. 

23.The ImageCenter Donor image is now stored on the Image server and ready to be used 

by ImageUltra Builder 

24.Copy PQIMGCTR.EXE, PQIMGCTR.OVL PQDPLCTR.RTC from the DeployCenter directory into 

the C:\IMAGES 

25.The donor image is now ready to be added as an ImageUltra Builder 

1.22.8 Add the donor image to the ImageUltra Builder repository 

See 1.16, “Create a base operating system Portable Sysprep Image” on page 54. 


1.22.9 Create a ImageUltra Builder Smart Image using the donor image as a 

base 

See 1.6, “ImageUltra Builder process to create a Smart Image” on page 17. 

1.22.10 Re-clone an ImageUltra Builder after the Smart Image has been 

deployed into the Service Partition 

Preparation 

In this example we will deploy the ImageUltra Builder Smart Image to a client service 

partition. The client hard disk content is then cloned to an imaging server. The cloned image 

can then be uni- or multi-casted to multiple clients of the same configuration. This cloning 

method is very useful for large rollouts of the same system configuration. 

Before beginning the cloing process you have to: 

► Connect the client to the ImageUltra Builder Repository 

► Use the ImageUltra Network deploy diskette to connect to the repository 

Deploying the Portable-Sysprep Smart Image 

1. Power on the client 

2. Make sure that the system boot from the IUB network deployment disk. 

3. When the system completes the boot process the ImageUltra builder Choose an image to 

Deploy menu will be displayed. 

4. Use the arrow keys to select the Base Map 


6. On the Deploying Driver Map select Yes 


8. Select the your Driver map 


10.On the ImageUltra Deploy menu confirm your selection of Base map and Driver map. 

11.Press Enter 

12.When you are prompted for Direct Network Install, select NO. By selecting no you will then 

deploy all IUB modules into the service partition of the donor system.Press Enter 

13.The system will launch an IUB deployment screen and reboot. 

14.The system will reconnect to the IUB repository and begin copying the ImageUltra 

modules down to the donor system. 

15.When completed you will see a message on the screen telling you that on the next 

REBOOT the system will install. 

16.Remove the ImageUltra Builder Boot disk from the donor 

17.Select EXIT 

18.You have now successfully created the ImageUltra Builder donor system and it is now 

ready to be cloned to the image distribution server. See 1.22.2, “Use PXE and Virtual Boot 

Environment to capture donor image” on page 95 for more details on how to capture your 

image. 


1.23 Image deployment 

In this section we will look at: 

► Unicast a cloned ImageUltra Smart Image (1.23.1, “Unicast a cloned ImageUltra Smart 

Image” on page 110) 

► Multicast a cloned ImageUltra Builder Smart Image (1.23.2, “Multicast a cloned IUB 

Smart Image” on page 115) 

1.23.1 Unicast a cloned ImageUltra Smart Image 

In this example we will create a virtual floppy that will deploy the cloned ImageUltra Builder 

Smart Image to a single system. 

1. Open the PowerQuest Boot Disk Builder 

2. Select Microsoft TCP/IP Boot Disk 

Figure 1-119 Microsoft TCP/IP Boot Disk 

3. Click Next 


4. Fill in all your required login fields as shown in Figure 1-120. 

Figure 1-120 Login settings 

5. Click Next 


6. Fill in your ImageCenter command line parameters. In our example below we used 

"/cmd=script.txt /img=basexp.pqi". See Figure 1-121. 

The script.txt file contains you image install commands, and your BASEXP.PQI is your 

actual image file. 

For details on using Symantec command line scripts please refer to the Symantec 

DeployCenter Guide. 

Figure 1-121 Enter command line parameters - 

The script file SCRIPT.TXT will be created using notepad as the last step in this example 

and will be saved into the \\server\images share. 

7. Click Next 


8. Select the network adapter driver for the client you will deploy to. 

Figure 1-122 Select Network Adapter 

9. Click Next 

10.Leave the default selection of DHCP 

Figure 1-123 Select the default option - DHCP 

11.Click Next 


12.Select the option to create a Virtual Boot Disk File 

13.Save Virtual Boot Disk File as Unicast Deploy IUB Smart Image 

14.Click Finish 

15.Your virtual boot disk file, Unicast Deploy IUB Smart Image.vfd, will be saved by default 

into: 

C:\Program Files\PowerQuest\DeployCenter 5.5\BDBUILD 

16.Save your configuration for future use if requested. 

17.Open the PowerQuest PXE Configuration Utility. 

In the PXE Virtual floppies tab and click the Add button and browse to the folder where 

your .vfd file is stored. 

C:\Program Files\PowerQuest\DeployCenter 5.5\BDBUILD\ 

18.Click OK. 

. 

Figure 1-124 Add Unicast Deploy IUB Script Image to PXE Configuration 

19.The server is now setup to accept PXE requests to deploy the ImageUltra Builder Smart 

Image. 

20.Before you start deploying the client, you will need to create a SCRIPT.TXT file. 

For our example we used the following script file: 

SELECT DRIVE 1 

DELETE ALL 

SELECT FREESPACE FIRST 

CREATE /FS=UNFORMATTED /SIZE=15000 POSITION=BEGINNING 

SELECT FREESPACE FIRST 

SELECT IMAGE 1 

RESTORE 

SELECT PARTITION LAST 

SET ACTIVE 

REBOOT 

21.Now you can use the UniCast IUB Smart Image menu option to deploy the cloned IUB 

Smart image. 


Power on your system and Press the F12 function key to select your network boot device 

and then press enter. 

Example: IBA GE SLOT 0208 v12O2 

1.23.2 Multicast a cloned IUB Smart Image 

In this example we will create a virtual floppy that will deploy the cloned ImageUltra Builder 

smart Image to multiple systems simultaneously using PowerCast. 

1. Open the PowerQuest Boot Disk Builder 

2. Select PowerCast Boot Disk 

Figure 1-125 Select PowerQuest Boot Disk 

3. Click Next 


4. Fill in all of the required fields for Client start-up mode. In our example we used the 

following: 

Connect to session: powercast1 

PowerCast image to hard disk number: 1 

Additional command line parameters: /PPR=FIRST /DSK=1 /NMD 

See the Symantec DeployCenter Guide for details on these command line parameters. 

Figure 1-126 Client start-up mode 

5. Click Next 


6. Select the required network adapter driver(s) required to support your target hardware. 

Figure 1-127 Select Network Adapter 


2. Leave the default select of DHCP and set the maximum number of PowerCast clients you 

will allow to be deployed simultaneously. In our example we used 10 clients. See 

Figure 1-128. 

Figure 1-128 Client network properties 



4. Select the option to create a Virtual Boot Disk file and enter the name of your virtual boot 

disk file as PowerCast IUB Super Image. See Figure 1-129. 

Figure 1-129 Enter VBD file super image name 

5. Click Finish 

6. Save your configuration file for future use 

7. Before adding the PowerCast IUB Super Image.vfd to the PXE Configuration utility you 

need to customize the autoexec.bat in the virtual floppy. 

8. Open the PowerQuest VF Editor. 


9. Open the PowerCast IUB Super Image.vfd file you have just created. 

Figure 1-130 VF Editor window 

10.Extract the AUTOEXEC.BAT into C:\Powerquest\Multicast directory 

Edit the AUTOEXEC.BAT, by adding the line: 

pqimgctr /cmd=i:\pscript.txt /nrd 

Figure 1-131 Edit the autoexec.bat file 

11.Save the AUTOEXEC.BAT to c:\program files\PowerQuest\DeployCenter 5.5 

12.Close the notepad window 

13.Delete the MOUSE.COM from the virtual floppy image 

14.Add the following files into the virtual floppy image: 

c:\program files\PowerQuest\DeployCenter5.5\pqimgctr.exe 

c:\program files\PowerQuest\DeployCenter5.5\pqimgctr.ovl 


c:\program files\PowerQuest\DeployCenter5.5\pqdplctr.rtc 

c:\program files\PowerQuest\DeployCenter 5.5\autoexec.bat 

Note: If while trying to add the above files you get a drive full error, go to the main menu 

and select Image →Change Format →select 2.88 mb 

Figure 1-132 Change drive format 

15.Save and exit the VF Editor 

16.Add the virtual floppy file to the PXE Configuration Utility and build a menu called 

PowerCast IUB Smart Image. See “Add the CAPTURE IMAGE.VFD to the Configuration 

Utility” on page 107, for an example of how to do this. 

17.Close the PowerQuest PXE Configuration Utility 

18.Create a PSCRIPT.TXT using notepad including the following text. 

SELECT DRIVE 1 

DELETE ALL 

DELECT FREESPACE FIRST 

CREATE /FS=UNFORMATTED /SIZE=15000 /POSITION=BEGINNING 

19.Add the PSCRIPT.TXT to the image share on the server. In our example this would be 

\\server\images. 

20.You are now ready to start the PowerCast server. 

21.Open up a command prompt on the PowerCast server and enter the following command: 

PQPCS32.EXE /fsd=15 /pcthr=500 

Figure 1-133 Command prompt to launch a PowerCast Window 


22.Press Enter 

23.This will open up the PowerCast window. 

24.Enter the Session Name and browse to the image file. 

In our example we used: Session Name: session1, Image File: BASEXP.PQI 

25.Click Start to start the PowerCast services on the server. 

26.Power-on the clients, press the F12 function key to boot the client to the network. 

Example: IBA GE Slot 0208 v1202 

27.Select the PowerCast IUB Super Image menu option to deploy the cloned IUB Smart 

image. 

28.When the clients connect to the PowerCast server they will queue up and wait for the 

PowerCast to start. 

29.When all of the clients have connected to the PowerCast session, click GO on the 

PowerCast Server Progress screen to deploy the cloned ImageUltra Builder Smart Image 

to the clients. 

1.24 Software integration considerations 

1.24.1 Integration with Web-D 

To enable Web-D for software distribution, ImageUltra Builder can be used to enable the 

agent. One problem that always comes up during the deployment of any software distribution 

tool is getting the agent installed on the clients. This is best accomplished by including the 

agent with the image. An application module can easily be created which will install the 

Web-D agent. The Web-D agent is installed using a program called esdsetup.exe. This setup 

can be included as part of the image and run silently using the following command: 

esdsetup.exe /s 

1.24.2 Integration with System Migration Assistant (SMA) 

SMA can easily be deployed as a module during an image load. This will allow for immediate 

restoration of user settings that may have been captured before a PC cascade or new system 

rollout. Create a silent install for the SMA tool as outlined below and create a module. Use the 

ImageUltra Builder tool to deploy the SMA module during your image installations. Once the 

image load is complete, run the SMA application and apply all of the saved user settings. The 

end user will have the same look, feel and data as with their previous system, saving valuable 

reconfiguration and down time. 

To create a silent install of SMA, follow these steps: 

1. For Windows NT 4.0 Workstation, Windows NT 4.0 Server, Windows 2000 Professional, 

Windows 2000 Server, Windows 2000 Advanced Server, or Windows XP Professional, log 

on to your computer as the administrator or as a user with local administrative rights. 

2. Download SMA code and documentation from: 


Please follow the instructions on the Web page to download this file. 

3. Make sure there are no other setup programs running. 


4. Launch the SMAsetup_.EXE program that you downloaded from the Internet, 

where stands for the language variation you are using. For instance, the English 

version of the executable is SMAsetup_en.exe. 

5. Wait until you see the Welcome window. Then minimize the SMA setup window, or bring 

up the command or Explorer window without exiting the SMA setup. 

6. Locate the pft*~tmp folder, where * stands for one or more random characters. If you’re 

running Windows 95, Windows 98, or Windows ME, you will find this directory in the 

C:\Windows\TEMP directory. On Windows NT 4.0 Workstation or Windows NT 4.0 Server, 

you will find this directory in the C:\Temp directory. On Windows 2000 Professional, 

Windows 2000 Server, Windows 2000 Advanced Server, or Windows XP Professional, 

you will find it in the C:\Document and Settings\\Local Settings\Temp\ 

directory. 

Note: The Local Settings Folder may be hidden by default. Select Tools →Folder 

Options →View and click Show hidden files and folders if the Local Settings Folder 

is not displayed. 

7. Copy the folder to the location where you want to keep the install files and rename it if you 

wish to do so (this folder location will be used in the next steps), then cancel SMA 

InstallShield setup. 

8. From the command line, run setup -r on a system which has the same configuration as 

the system for which you are creating the silent install. The executable setup.exe is located 

in the setup directory you just copied in the Disk1 folder. This will create an InstallShield 

response file named setup.iss in the C:\windows or C:\winnt directory (depending on your 

operating system). For more information on the setup command, see various articles on 

silent installation at http://support.installshield.com/. 

9. Now you are ready to install SMA in silent mode. To do so, copy the setup.iss file to the 

setup directory you created previously and from the command line run setup –s –SMS. 

Alternatively, you can run setup.exe -s –SMS –f1\setup.iss, where the f1 

parameter denotes the location of setup.iss file. 

10.When the install has completed, open the setup.log file located in the setup directory and 

locate the ResultCode variable in the [ResponseResult] field. If Resultcode = 0, the 

installation completed successfully. Common error values are: 

-3 Required data not found in SETUP.ISS file 

-5 File does not exist 

-8 Invalid path to the InstallShield response file 

-12 Dialogs are out of order 

1.24.3 Integration with Software Delivery Assistant (SDA) 

There are two ways of integrating your Software Delivery Assistant image into the ImageUltra 

Builder process. Here are a few examples. 

SDA module with menu integration 

Here we will show an example of how to integrate an SDA Image into an ImageUltra image. 

We will create a module that contains the SDA Image. The user will select their business 

group from the ImageUltra menu. A utility will create an SDAPROF.INI that contains the 

appropriate business group. This file will reside in the IBM Service Partition (the only partition 

available at this stage). We will need to create another module that will copy the 


SDAPROF.INI to the root of C: during the auditboot cycle.The SDA module will install during 

the ImageUltra installation process. It will pick up the SDAPROF.INI in C:\ and install the 

applications for the group the user selected earlier. 

Note: This example assumes that we are not selecting a direct network install. Instead, we 

are deploying to the service partition. 

The benefit of doing this is that we have one flow, with minimal user interaction (the user only 

selects his/her options in the ImageUltra menu). 

Here is what you need to do: 

1. Create a base map that contains Menu Items matching your SDA groups. 

Figure 1-134 Integrating SDA, base map 

2. For each of the Menu Items, create a utility that writes the appropriate SDAPROF.IN 

a. In the ImageUltra Builder program, click the Utility tab and select Insert →Utility. 

b. Step through the New Module Wizard. 

c. When the module properties window pops up, click the Source tab and type in the 

location of your the batch file that creates the SDAPROF.INI for that specific Menu Item 

under the Source directory field. For our example, the file for the Finance item is called 

FINANCE>BAT and is located in D:\Source\Utilities. 


Figure 1-135 Building a utility for writing the SDAPROF.INI 

Example 1-1 Batch file for creating an SDAPROF.INI (FINANCE.BAT) 

Rem create an SDAPROF.INI 

cls 

echo [User Information]>c:\iutemp\sdaprof.ini 

echo GROUP=Finance>>c:\iutemp\sdaprof.ini 

Note: At this stage of the process, the partitions have not been created yet. There is 

only the IBM Service Partition which is drive letter C: 

3. Attach a utility for each of the Menu Items. 

Figure 1-136 Attach Utility to Menu Item 

4. Create a module that copies the SDA image onto the users hard disk. In our example, it is 

called SDA image. 

a. In the ImageUltra Builder program, click the Applications tab and select 




c. When the module properties window opens, go to the Source tab and type in the 

location of your SDA image under the Source directory field. For our example, the files 

are in D:\Source\SDA. 

Figure 1-137 Building a module for an SDA image, Source tab 

d. Click the Options tab. Type the directory where you want the SDA image to reside on 

the user’s hard disk. For our example, we will enter \SDA. 

Figure 1-138 Building a module for an SDA Image, Options tab 

e. Build the module. 


5. Create a module that puts the SDAPROF.INI in the root of C: 




Figure 1-139 Module for copying the sdaprof.ini 


location of a batch file that will copy the SDAPROF.INI from the IBM Service Partition to 

the root of C:\. For our example the file is called copyini.bat and resides in the 

D:\Source\sdaprof directory. 

Example 1-2 Batch file that copies the Sdaprof.ini to the root of C:\ (copyini.bat) 

Rem copies the SDAPROF.INI from the IBM Service PArtition to C:\ 

copy d:\IUTEMP\SDAPROF.INI c:\ 

Note: This module will execute during the auditboot cycle; at this stage of the process, 

the IBM Service Partition has the drive letter D:. 

6. Create a module that starts the SDA installer automatically. 





Figure 1-140 Create a module that automatically starts SDA Installer 


location of a batch file that will start the SDA installer under the Source directory field. 

For our example, the file is called sda.bat and resides in the D:\Source\SDA Autostart 

directory. 

Example 1-3 Batch file to start SDA Installer (sda.bat) 

Rem Autostart the SDA Installer 

c:\SDA\SWSELECT.EXE 

C:\SDA\WAIT 5 

C:\SDA\SSWAIT.EXE 

Note: SSWait.exe is a program, included with the SDA source files, that waits until the 

SDA installer has finished before returning control to the process. Wait.com is not part 

of the SDA code; it puts a small delay in to make sure that SSWait.exe kicks in properly. 

If you do not have wait.com, you can use any utility that performs the same function. 

SDA image on a server 

Another method of integrating your SDA image into an ImageUltra solution is to include a 

shortcut that points the user toward a server location where the SDA image resides. This 

method can be used when the SDA image is large in size. 

For our example, the SDA image is on a server with IP address 10.1.1.1 in the shared folder 

SDA. We will build a module that puts a batch file on the user’s hard disk. This batch file will 

connect to the server share, run the SDA install and then disconnect from the server again. A 

shortcut to the batch file will also be placed on the desktop. 

1. Create a batch file that will connect to the server share and start the SDA install. In our 

example, we used the following file: 

Example 1-4 Batch file for connecting to SDA share on server (connect.bat) 


Rem Connect Network Drive 

net use z: /del>NUL 

net use z: \\10.1.1.1\SDA /USER:SDAUSER temp 

Rem Start SDA Installer 

z:\SWSelect.exe 

z:\wait 5 

z:\sswait.exe 

================================================== 

Rem Disconnect Network Drive 

net use z: /del>NUL 

2. On a source machine, create a shortcut that will point to the batch file on the target 

machine. For our example, we are going to put the batch file in the directory C:\SDA on the 

user’s machine, so we point the shortcut to this location. 

Figure 1-141 Shortcut to batch file 

3. Create the module. 

1.24.4 IBM Rescue and Recovery 

For details on how to prepare and create a silent install module for IBM Rescue and 

Recovery, please refer to Section 2.3.4, “Silent Installation” in Using ThinkVantage 

Technologies: Volume 2 Maintaining and Recovering Client Systems, SG24-6060-01. 


1.24.5 ImageUltra Builder with Symantec Ghost 

When Ghost is used in conjunction with the ImageUltra Builder program, certain limitations 

must be considered. Symantec Ghost can clone partitions and drives. 

Because the ImageUltra Builder program uses a service partition to store the Smart Image for 

certain types of installations, Symantec Ghost might encounter problems when attempting to 

set the size for multiple partitions or when installing a cloned drive. When defining partition 

sizes as a percentage, Ghost always uses the full hard-disk capacity and does not take the 

presence of a service partition into account. As a result, Ghost might delete the service 

partition on the target computer. Defining absolute sizes can be equally problematic because 

drive sizes vary on target computers. 

When using a cloned drive, two problems can occur: 

► If a service partition exists on a source computer, Ghost includes this service partition as 

part of the image and will overwrite the service partition on the target computer. This 

results in a mismatch between the contents on the active partition of the target computer 

and the service partition of the target computer. 

► If a service partition does not exist on the source computer, Ghost will assume that it can 

use the entire hard disk for the image, and will delete the service partition on the target 

computer. 

Because it is so difficult to manage multiple partitions and cloned drives created by Ghost 

when a service partition is present, IBM supports the following implementations only: 

► Restoring single-partition images produced by Ghost 

► Restoring a single-partition, cloned-drive image as a single partition, not as a cloned drive. 

The silent install command in the Source tab of the Operating System window must be a 

batch file name, such as GHOST.BAT. Inside the batch file, you must use the following 

statements: 

Gdisk.exe 1 /cre /pri /sure 

ghost.exe -clone,mode=pload,src=image.gho:1,dst=1:1 -auto -sure -quiet -fx -batch 

where image.gho is the name of your image. 

Before you build the module, you must put the image files, the script file, and the batch file in 

the same folder. 

1.25 Business case 

This section describes a sample business environment and ImageUltra Builder usage 

scenarios. 

1.25.1 Example organization 

The organization used in this section is named Acme Holdings Inc. (see Figure 1-142). This 

company has offices in New York, Toronto, London and Madrid. The head office is located in 

New York where the main IT Development team also exists. The various sites are connected 

via T3 and T1 lines; this allows the locations to communicate with each other. Images using 

ImageUltra Builder are developed in New York where all updates are made to the “Master 

Repository”. For distribution, this information is replicated to local site replicas where system 

loads are performed. 


The hardware in this organization consists of IBM and non-IBM workstations. Existing 

images, created using Symantec Ghost and Symantec DeployCenter, are currently used to 

prepare/reload these workstations. Acme Holdings Inc. would like to continue use of these 

images until those machines are retired. 

Replica A 

Toronto 

2000 

Users 

Replica B 

Figure 1-142 Acme Holdings Inc. 

As Acme Holdings Inc. migrates to full use of ImageUltra Builder (and supporting 

technologies), they will first add their hardware-specific images. Going forward, they will use 

Portable-Sysprep and UltraPortable imaging technology to deploy their new workstations in 

order to ensure that they have maximum flexibility. 

As part of the maintenance process, the Master repository located in New York is replicated 

to support replicas (one in each location). This allows the support staff to access the images 

at each location without putting excessive loads over the WAN links. 

Service Partition: The purpose of the service partition 

Using the IBM ImageUltra method, you can select to deploy directly over the network or use a 

service partition. The service partition is a hidden partition on a hard disk from which the 

ImageUltra builder deploys the operating-system modules, application modules, device-driver 

modules, and a set of recovery tools. It also provides its own boot environment for image 

deployment, which has no dependency on the Windows operating system being present on 

any active partition. Because the service partition is protected from common read and writes 

operations as well as most viruses, it is a practical place to store recovery, backup, and 

installation files and tools. 

The system partition is used for the following purposes: 

As shipped from the factory on IBM HIIT-enabled computers, the service partition provides a 

recovery mechanism to restore the contents of the hard disk to its factory-installed state. It 

also provides a vehicle for distributing IBM-developed modules that the ImageUltra Builder 

program can import. These modules can be a core OS modules created by IBM or a OS 

image created by Symantec DeployCenter and application and device drivers models 

provided by IBM for ImageUltra Builder. 


T3 

T1 

New York 

5000 

Users 

T3 

London 

2000 

Users 

Replica C 

T1 

T1 

Master 

Repository 

Madrid 

1000 

Users 

Replica D

As used by the ImageUltra Builder program, it is a storage area for deployed Smart Images 

and for the tools required to perform the image installation process. Smart Images replace the 

factory installed image files in the service partition. If a service partition is not on a target 

computer before a Smart Image is deployed, one is created during the deployment process. 

1.25.2 Business case section 1 of 3: Using hardware specific images 

Table 1-1 Acme Holdings Inc. 

This is an example of migrating from legacy images to hardware specific OS modules. In this 

business case, we will show how a large corporation migrates from an existing monolithic 

image process to a module system build process using ImageUltra Builder 2.0. The following 

table gives an overview of the current state and a three-phased approach to migrating to 

ImageUltra Builder. 

Existing State Phase I legacy 

systems 

Method Legacy Ghost images Hardware-specific 

using ImageUltra 

Builder 

Operating 

Systems 

Hardware 

platforms 

Four: 

► Windows 95c 

► Windows 98 

► Windows NT 4 


older systems have 9x 

or NT4 and the newer 

systems have 2000 

only 

Eight: 

► Compaq EN 

desktop 

► Toshiba Tecra 

8100 

► HP VL 8i 

► IBM PC 300® PL 

► HP VL 420 


9000 

► IBM M40 

NetVista 

► IBM T23 ThinkPad 

Technology Legacy monolithic 

ghost images 

Three: 




Four: 

► Compaq EN 

desktop 


8100 

► HP VL 8i 

► IBM PC 300 PL 

Hardware Specific OS 

modules incorporating 

the existing legacy 

images 

Phase II current 

systems 

Portable-sysprep 



One: 

► Windows 2000 on 

multiply vendor 

platforms 

► Two modules 

containing the 

unique HALs are 

required to support 

the four systems 

Four: 

► HP VL 420 


9000 

► IBM M40 NetVista 


Sysprep OS module 

combined with 

modules for drivers, 

patches and 

applications. 

Phase III future 

systems 

Ultra-portable 

ImageUltra Builder 

One: 

► Windows XP on 

IBM hardware 

Two: 

► IBM M50 

ThinkCentre 


Ultra-Portable OS 

module provided by 

IBM with all new 

systems combined 

with modules for 

drivers, patches and 

applications 


Business Units Six: 

► Sales 

► IT 

► Manufacturing 

► Field 

► Engineering 

► Finance 

Languages Three: 

► English - US 

► English - UK 

► Spanish 

Unique system 

combinations 

supported 

Images to 

create 

Existing State Phase I legacy 

systems 

Method Legacy Ghost images Hardware-specific 



216: One for each 

combination of 

hardware platform, 

business unit, and 

language. 

Six: 

► Sales 

► IT 


► Field 


► Finance 

Three: 



► Spanish 





language. 

Acme Holdings Inc. is typical of many large corporations. Acme Holdings Inc. has eight 

different hardware platforms, four laptops and four desktop models. The older four models 

have two different operating systems (OS) on them; this is a mixture of Windows 95, 98 and 

NT 4, while the newer systems only have Windows 2000 installed on them. This results in 

twelve unique hardware/OS combinations: ((4X2) +(4X1))=12. It would not be unreasonable 

for a large company to support up to ten different languages, but for our example we will use 

three; this results in 36 unique hardware/OS/language combinations. The final variable that 

must be addressed is the different business units. For image development and maintenance, 

a business unit is defined as any group of end users that have similar software application 

requirements. Acme Holdings Inc. has six business units but 20 or more would not be 

unrealistic. The end result is that 216 unique system builds must be maintained and 

supported. 

The typical means to support these 216 unique combination is to create one monolithic image 

to use a tool such as PowerQuest Drive Image or Symantec Ghost for each unique 

combination. In this type of solution, each combination is built one at a time. Then a copy of 

the system is made using one of the tools listed above. This single file copy of the system is 

called an image. 

The time is takes to build each one of these images varies greatly depending on the OS and 

the number, size and complexity of the applications required. An experienced image creator 


Phase II current 

systems 

Portable-sysprep 



Six 

► Sales 

► IT 


► Field 


► Finance 

Three: 



► Spanish 





language. 

216 144 6 1 

Phase III future 

systems 

Ultra-portable 


Six: 

► Sales 

► IT 


► Field 


► Finance 

Three: 



► Spanish 





language. 

Note: The following process assumes that the reader has installed and configured 

ImageUltra Builder as detailed earlier in this document. It is also assumed that the reader 

has read and understands all of the details presented so far in this document concerning 

ImageUltra Builder.

could reasonably create and test one image per day. At Acme Holdings Inc., it would take one 

person most of a year to create all of the 216 unique images or a large staff of image creators 

to create and maintain this number of images. 

If one small change occurs, such as an OS patch needing to be added to the images, then 

each one must be recreated. There clearly must be a better way to create unique system 

builds. The issue is maintaining these images. 

Acme Holdings Inc. has decided to use IBM ImageUltra to reduce the time and complexity of 

system building. IBM ImageUltra Builder V2.0 provides a means to significantly reduce the 

number and complexity of the system build process. This is done using a modular approach 

which can greatly reduce the number of unique modules that must be created. 

Before introducing ImageUltra Builder to Acme Holdings’s build environment, we must 

determine how it will be used. First, we must determine which systems will benefit from the 

process the most and which system will be retiring in the near future. If a system is already 

three years old and only a few will be rebuilt each year then it is not efficient to create a new 

build for these types of systems. An example of this type of system would be a 300 Mhz PC 

running Windows 95 that was purchased in 1999. If this system fails, it will most likely be 

replaced. 

In the event that it must be rebuilt, the existing image process that Acme Holdings Inc. is 

currently using would be able to return the system to its pre-failure state. After considering 

age, operating systems and performance, Acme Holdings Inc. has decided to move half of 

their systems to the new ImageUltra process and leave the older half with the current image 

process. The results are shown in Table 1-2 on page 133. 

Table 1-2 Phase 1 and 2 

Phase 1 Phase 2 

Systems Older legacy system Current systems 

Operating Systems Windows 95,98se, NT 4 Windows 2000 

Models ► Compaq Deskpro EN 

► HP VL 8i 


► Toshiba Tecra 8100 

technology hardware specific modules 

created from legacy images 

► HP VL 420 




sysprep OS module combined 

with modules for drivers, 

patches and applications 

Unique system builds 144 unique images 6 unique OS modules used in 

72 unique builds 

This division from older systems to newer ones provides a logical migration point from the 

legacy imaging process to the new modular ImageUltra process. ImageUltra provides 

hardware-specific OS module support. This support provides a means to ease the transition 

and to introduce the Acme Holdings Inc. support staff to ImageUltra Builder. 


Table 1-3 Phase 1 

The first step in this process is to create one hardware specific OS module in ImageUltra 

Builder for each of the existing legacy images. The following process will show the steps 

required to bring these legacy images into the new ImageUltra process without modifying the 

existing images. 

The next section will discuss the creation of portable-syspreped images which Acme Holdings 

Inc. will be using for the newer four models listed above running Windows 2000 

1.25.3 Business case section 2 of 3: Using portable-sysprep images 

In the previous section, we demonstrated how Acme Holdings Inc. began to introduce 

ImageUltra Builder into their environment. Acme Holdings Inc. did this by building hardware 

specific modules to bring all their legacy images into ImageUltra Builder. After creating the 


Existing State Phase I legacy systems 

Method Legacy Ghost images Hardware Specific using 


Operating Systems Three: 




Hardware platforms Four: 

► Compaq EN desktop 


► HP VL 8i 


Three: 




Four: 



► HP VL 8i 


Technology Legacy monolithic ghost images Hardware Specific OS modules 

incorporating the existing legacy 

images 


► Sales 

► IT 


► Field 


► Finance 




► Spanish 

Unique system 

combinations supported 

144: One for each combination of 

hardware platform, business unit, 

and language. 

Images to create 144 144 

Six: 

► Sales 

► IT 


► Field 


► Finance 

Three: 



► Spanish 



and language.

144 hardware specific OS modules, we are left with 72 existing images that support the 

remaining four hardware platforms running Windows 2000 in three different languages. 

Now that Acme Holdings Inc. has become familiar with building OS modules for their legacy 

images, they could repeat this same process to build 72 additional new Window 2000 

hardware specific modules. This would defeat the purpose of using ImageUltra Builder. By 

using ImageUltra Builder, we can reduce the number of unique images from 72 down to six 

OS modules. 

This great reduction is made possible by breaking the system build down into a modular 

process. A legacy image has one image file containing the OS, drivers, and applications. The 

result is when a small change needs to me made the entire image must be recreated. 

Additionally, by using the ImageUltra modular process, the OS module can take advantage of 

the OS’s built-in features that enable a single OS module to be used on more than one 

hardware platform. 

To use this portable OS module, we will need a sysprep Windows 2000 image that has had 

the hardware specific drivers removed. To create a sysprepped image, refer to 1.16, “Create a 

base operating system Portable Sysprep Image” on page 54. 

With the sysprep image, we only need to consider the HAL compatibility of the hardware 

platforms. For more information concerning HAL compatibility, refer to Microsoft’s Web site for 

details on HAL cross-platform compatibility. We have determined that at Acme Holdings Inc. 

they will require two images to support two unique HALs. The HAL of the HP VL 420 desktop 

and the IBM M40 NetVista desktops were determined to be compatible and the HAL of the 

Toshiba Tecra 9000 and the IBM T23 ThinkPad were determined to be compatible. 

We now have a decision to make concerning languages. Since Windows 2000 supports 

multiple languages, we can build one multi-language portable-sysprep image for each of the 

two unique HALs. The other option is to keep the portable-sysprep images language-specific. 

If the first option is taken, the result will be two images to support four hardware platforms 

using three languages. If the second choice is used, the result will be six images to support 

four hardware platforms using three languages. 

Table 1-4 on page 135 shows some of the advantages, disadvantages and features of both 

options. This information will be needed to make an informed decision as to whether or not 

(and where) to use a multi-language sysprepped OS image. 

Table 1-4 Multi-language OS image 

Type Of OS image Multi-Language Single Language 

Size Larger Smaller 

Complexity of development Complex Simple 

Developer Must be multi-lingual Only needs to know one 

language 

changes needed that affect only 

one language 

distributed development and 

division of workload 

Must rebuild entire image Only need to change impacted 

language image 

1 developer per image 2 

developers maximum at Acme 

Holdings Inc. 

1 developer per image; 6 

developers maximum at Acme 

Holdings Inc. 

Distribution time Slower due to larger image size Faster due to smaller image 

size 

Total number of OS modules 2 6 


Acme Holdings Inc. has decided that they will keep their images language-specific. This 

means that they need to create and maintain six images, instead of two if they had opted for 

the multi-language images. Two of the major reasons that supported this decision for Acme 

Holdings Inc. were: 

► Acme Holdings Inc. is just learning how to create sysprep images and 

► They have developers with different language skills located in different countries. 

This allows Acme Holdings Inc. to utilize the greatest number or developers at one time. As 

the development staff gets more proficient with sysprepped images they may decide to move 

to the multi-language images. The advantage of using the ImageUltra Builder process is that 

when the company does change to the multi-language images, the developer will only need to 

replace the existing OS modules with the new ones. No other modules will need to be 

recreated or modified. 

Table 1-5 Phase 2 


Existing State Phase 2 current systems 

Method Legacy Ghost images Portable-sysprep using ImageUltra 


Operating Systems One: 


Hardware platforms Four: 

► HP VL 420 




One: 

► Windows 2000 on multiply 

vendor platforms 

► Two modules containing the 

unique HALs are required to 

support the four systems 

Four: 

► HP VL 420 




Technology Legacy monolithic ghost images Sysprep OS module combined with 

modules for drivers, patches and 

applications. 


► Sales 

► IT 


► Field 


► Finance 




► Spanish 

Unique system 

combinations supported 



and language. 

Six 

► Sales 

► IT 


► Field 


► Finance 

Three: 



► Spanish 



and language.

A close look at Table 1-5 on page 136 will reveal that Acme Holdings Inc. is missing one key 

part of their system builds. There are no applications built into these six language-specific OS 

modules. All components of a unique system combination in ImageUltra are separate 

modules. We must now create application modules for each of the applications that our six 

business units require. 

Business units and application 

The following is a list of the business units and abbreviations used in the table below. 

► common = applications that are installed on all systems 

► 1 = Sales 

► 2 = IT 

► 3 = Manufacturing 

► 4 = Field 

► 5 = Engineering 

► 6 = Finance 

Table 1-6 shows the different applications and the business units that use them. 

Table 1-6 Applications and business units 

Existing State Phase 2 current systems 

Method Legacy Ghost images Portable-sysprep using ImageUltra 



Applications Business Unit 

Corel WordPerfect Office Suite 11 Common 

Microsoft Internet Explorer 6.0 Common 

Norton Antivirus Common 

Lotus® SameTime Chat Common 

AT&T Network Client 1,2,4 

Time accounting Common 

Lotus Notes® 4,5,6 

Eudora e-mail client Common 

Adobe PhotoShop 2 

Adobe FrameMaker 2 

Rumba host emulator 2,3,5,6 

Adobe Acrobat reader Common 

Adobe Acrobat 2,5 

Filezilla FTP client 2,5 

Opera 7.11 web browser 2,5 

Macromedia Dreamweaver Studio MX 2,5 


Figure 1-143 OS map module 

Applications Business Unit 

DeLorme Street Atlas 1,4 

Zone Lab firewall 1,2,4 

Rarlab - WinRAR Common 

Sun Java Runtime environment 1.4.1_03 Common 

Nero CD creations 2 

AutoCAD 2002 5 

Pro-E CAD 5 

Microsoft Java Virtual Machine 3809 Common 

MiniTab statistical analysis 6 

Vcom Fit-it Utilities 5 2 

Xn-View picture editor 2,5 

Microsoft Active Sync 1,2,4 

IBM ImageUltra Builder 2 2 

IBM System Migration Assistant 2 

IBM Software Delivery Assistant 2 

IBM Access Connections 1,2,4 

IBM Web-D 2 

VPN client 1,2,4 

Each one of these applications must be made into an application module as demonstrated in 

1.10, “Creating an application module from source files” on page 28. These application 

modules are reusable, so each application only needs to be made into a module once. This 

module can then be deployed to as many business units as required without any additional 

effort. This is accomplished through the use of maps. Refer to the Use driver map filter 

processing under 1.19.1, “Driver Map settings” on page 82. 

The following window shows the map for a Windows 2000 portable-sysprep OS for the 

Spanish IT department. 


Figure 1-144 is the first menu window generated by the map shown in Figure 1-143. 

Figure 1-144 Preview of OS map module - first window 

The following is the second window generated by the OS map module shown above. 

Figure 1-145 Preview of OS map module - second window 

This is a folder containing application modules for use on the UK English version of Windows 

2000. 


Figure 1-146 Repository - UK English applications 

The above figure shows the logic tree details for the base map showing desktop applications 

on UK English. 

1.25.4 Business case section 3 of 3: Using ultra-portable 

In the previous section, we demonstrated how Acme Holdings Inc. could use 

portable-sysprep images to move their Windows 2000 current systems from the old legacy 

imaging process to the ImageUltra modular process. Acme reduced 72 images into six 

portable image module to support the same 72 unique system configurations. 

Acme Holdings Inc. is planning to migrate to Windows XP running on IBM-only hardware for 

all future PC systems. They could continue to use this same portable solution as they are now 

using for Windows 2000 but the move to IBM hardware offers a better solution. IBM provides 

a special ultra-portable OS module for use on IBM equipment. These ultra-portable modules 

are available for Windows 2000 and XP. 

The advantage of the ultra-portable module over the portable-sysprep images is that the 

ultra-portable OS module can be used with any IBM system that supports Windows 2000 or 

XP. The HAL compatibility issues that we had to consider with the sysprep images are now 

resolved. With only two current portable-sysprep OS modules, this ultra-portability may not 

seem significant, but it really is. As new systems are introduced to Acme Holdings Inc.’s 

environment, the number of portable-sysprep modules will increase. Using the IBM provided 

ultra-portable OS module with the new systems will enable Acme Holdings Inc. to utilize a 

single OS module to support all of their new IBM laptops and desktops. 

Migration to this new ultra-portable system will require much less effort than the migration 

from legacy images to the portable-sysprep system. This is because all of the time and effort 

that went into creating the application modules does not have to be duplicated. All of the 

modules in the ImageUltra Builder’s repository are can be used to build as many unique 

system configurations that are needed. The only modules that are different between the 

portable-sysprep and the ultra-portable are the OS modules. All other modules can be reused 

as needed. 

In the future, Acme Holdings Inc. could start using the ultra-portable system for their older 

IBM models. To do this, they would replace the sysprep-portable OS module with the 


ultra-portable OS module and add any required driver modules for each IBM system that they 

need to support. 

Figure 1-147 Repository - XP Ultra portable OS module 

Table 1-7 Phase III 

Existing State Phase III future systems 

Method Legacy Ghost images Ultra-portable ImageUltra Builder 

Operating systems Four: 





Older systems have 9x or NT4 

and the newer systems have 

2000 only 

Hardware platforms Eight: 



► HP VL 8i 


► HP VL 420 




One: 

► Windows XP on IBM hardware 

Two: 

► IBM M50 ThinkCentre 


Technology Legacy monolithic ghost images Ultra-Portable OS module provided by IBM with all new 

systems combined with modules for drivers, patches 

and applications 



► Sales 

► IT 


► Field 


► Finance 




► Spanish 

Unique system 

combinations 

supported 

Existing State Phase III future systems 

Method Legacy Ghost images Ultra-portable ImageUltra Builder 



and language. 


This transformation at Acme Holdings Inc. did not happen overnight. This process took place 

over a three year time frame. The implementation of a new system build process was done 

through attrition. Older systems were rebuilt using the processes described above as system 

rebuilds were required or as systems were transferred to new users. The new systems would 

adopt the ImageUltra process the first time they were deployed. 

Acme Holdings Inc. combined the use of ImageUltra Builder and the reduction of hardware 

and operating systems. This resulted in: 

► Less time spent building and updating system builds 

► Lesser cost of maintaining systems 

► Greater standardization of platforms 

► Single operating systems environment 

The following table summarizes the changes that have taken place by moving from the legacy 

image system to the modular IBM ImageUltra Builder system of system build creation. 

Table 1-8 Before and after comparison 

Acme Holdings Inc. Before After 


Six: 

► Sales 

► IT 


► Field 


► Finance 

Three: 



► Spanish 

36: One for each combination of hardware platform, 

business unit, and language. 

Unique system combinations 216 36 

Hardware platforms 8 2 

Operating systems 4 1 

Images 216 1

Acme Holdings Inc. Before After 

Features Legacy monolithic images 

► Hardware dependent 

► OS/drivers/applications 

are all included 

► No reusable parts, any 

changes require complete 

recreation 

IBM ImageUltra Builder 

► Hardware independent 

► OS/drivers/applications 

are modularized 

► All modules are reusable. 

► Individual modules can be 

modified independently 

The next section, 1.17, “Customize an Ultra-Portable operating system module” on page 63, 

will show that the UltraPortable image can be customized to meet any customer’s needs. The 

section, 1.8.1, “Importing modules from an IBM recovery CD set” on page 22, will 

demonstrate the ability to import the modules provided by IBM into the repository. This is the 

quickest and easiest means to populate the repository with the driver and OS modules 

needed for each system. 



Abbreviations and acronyms 

AD Asset Depot 

AES Advanced Encryption Standard 

ANSI American National Standards 

Institute 

API application programming interface 

APS Active Protection System 

ATAPI Advanced Technology Attachment 

Packet Interface 

BEER Boot Engineering Extension 

Record 

BIOS Basic Input/Output System 

BSOD blue screen of death 

CA Certificate Authority 

CAPI cryptographic application 

programming interface 

CHS cylinders, heads, sectors 

CISC Complex Instruction Set Computer 

CSS Client Security Software 

DLL dynamic link library 

DLT digital linear tape 

DSL Digital Subscriber Line 

EAP Extensible Authentication Protocol 

ECC error checking and correcting 

EEPROM Electrically Erasable 

Programmable Read Only Memory 

EFS Encrypted File System 

ESD electronic software distribution 

ESS Embedded Security Subsystem 

FFE File and Folder Encryption 

GIF CompuServe Graphics Interchange 

Format 

GINA Graphical Identification and 

Authentication 

GSK Global Security Toolkit 

GUI Graphical User Interface 

HDD Hard Disk Drive 

HPA Hidden Protected Area 

HTML Hypertext Markup Language 

IBM International Business Machines 

Corporation 

IDE Integrated Drive Electronics 

IE Internet Explorer 

IP Internet Protocol 

ISO international Standards 

Organization 

ITSO International Technical Support 

Organization 

IUB ImageUltra Builder 

JDBC Java database connection 

JDK Java Development Kit 

JRE Java Runtime Environment 

LBA Logical Block Addressing 

LDAP Lightweight Directory Access 

Protocol 

LEAP Lightweight Extensible Application 

Protocol 

LPC low pin count 

LTO linear tape open 

MBR Master Boot Record 

MDAC Microsoft Data Access 

Components 

MSCAPI Microsoft Crypto API 

MSI Microsoft Software Installation 

NDIS Network Driver Interface 

Specification 

NIC Network Interface Card 

NLS National Language Support 

NTFS New Technology File System 

OEM Original Equipment Manufacturer 

PARTIES Protected Area Runtime Interface 

Extension Services 

PEAP Protected Extensible Authentication 

Protocol 

PKCS Public Key Cryptographic Standard 

PKI Public Key Infrastructure 

PTA Personal Trust Agent 

PXE Pre-boot Execution Environment 

RAID Redundant Array of Inexpensive 

Disks 

RDM Remote Deployment Manager 

RISC Reduced Instruction Set Computer 

ROI Return on Investment 

RSA Rivest, Shamir, and Adleman 

RTE Java Runtime Environment 


SCSI Small Computer Systems Interface 

SDA Software Delivery Assistant 

SDD Secure Data Disposal 

SDK Software Developer’s Kit 

SID Security Identifier 

SMA System Migration Assistant 

SMBIOS Systems Management Basic Input 

Output System 

SQL Structured Query Language 

TAM Tivoli Access Manager 

TCG Trusted Computing Group 

TCO total cost of ownership 

TCPA Trusted Computing Platform 

Alliance 

TFTP Trivial File Transfer Protocol 

TKIP Temporary Key Integrity Protocol 

TLS Transport Layer Security 

UDB Universal Database 

USB Universal Serial Bus 

UVM User Verification Manager 

VBE Virtual Boot Environment 

VPN Virtual Private Network 

WEP Wireless Equivalent Privacy 

WINS Windows Internet Naming Service 

WPA Wi-Fi Protected Access 

WMI Windows Management 

Instrumentation 

XML eXtensible Markup Language 

AD Asset Depot 

AES Advanced Encryption Standard 

ANSI American National Standards 

Institute 

API application programming interface 

APS Active Protection System 

ATAPI Advanced Technology Attachment 

Packet Interface 

BEER Boot Engineering Extension 

Record 

BIOS Basic Input/Output System 

BSOD blue screen of death 

CA Certificate Authority 

CAPI cryptographic application 

programming interface 

CHS cylinders, heads, sectors 

CISC Complex Instruction Set Computer 

CSS Client Security Software 


DLL dynamic link library 

DLT digital linear tape 

DSL Digital Subscriber Line 

EAP Extensible Authentication Protocol 

ECC error checking and correcting 

EEPROM Electrically Erasable 

Programmable Read Only Memory 

EFS Encrypted File System 

ESD electronic software distribution 

ESS Embedded Security Subsystem 

FFE File and Folder Encryption 

GIF CompuServe Graphics Interchange 

Format 

GINA Graphical Identification and 

Authentication 

GSK Global Security Toolkit 

GUI Graphical User Interface 

HDD Hard Disk Drive 

HPA Hidden Protected Area 

HTML Hypertext Markup Language 

IBM International Business Machines 

Corporation 

IDE Integrated Drive Electronics 

IE Internet Explorer 

IP Internet Protocol 

ISO international Standards 

Organization 

ITSO International Technical Support 

Organization

Related publications 

IBM Redbooks 

The publications listed in this section are considered particularly suitable for a more detailed 

discussion of the topics covered in this Redpaper. 

For information on ordering these publications, see “How to get IBM Redbooks” on page 148. 

Note that some of the documents referenced here may be available in softcopy only. 

► ThinkVantage Technologies: Volume 1 Creating and Deploying Client Systems, 

SG24-7045 

► ThinkVantage Technologies: Volume 2 Maintaining and Recovering Client Systems, 

SG24-6060 

► Using Web-D for Software Distribution, REDP-3764 

► Implementing Systems Management Solutions using IBM Director, SG24-6188 

► Using the System Installation Tool Kit to Streamline Client Rollout, SG24-6178 

Other publications 

Online resources 

These publications are also relevant as further information sources: 

► ImageUltra Builder Version 2.0 User Guide 

► IBM System Migration Assistant 4.1 User’s Guide 

These Web sites and URLs are also relevant as further information sources: 

► ImageUltra Builder patches 


► Hardware Independent Imaging Technology (HIIT) enabled PCs 

http://www.ibm.com/pc/support/site.wss/MIGR-44316.html 

► Microsoft Sysprep program 

http://www.microsoft.com/windows2000/downloads/tools/sysprep/license.asp 

► Windows NT 4.0 Resource Kit Support Tools 

http://www.microsoft.com/ntserver/nts/downloads/recommended/ntkit/ 

default.asp 

► Windows 2000 Resource Kit 

http://www.microsoft.com/windows2000/techinfo/reskit/default.asp 

► IBM Imaging Technology Center (IITC) 

http://www.pc.ibm.com/cbcc/cbccweb.nsf/Home 


How to get IBM Redbooks 

Help from IBM 

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft 

publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at 

this Web site: 

ibm.com/redbooks 

IBM Support and downloads 

ibm.com/support 

IBM Global Services 

ibm.com/services 


Index 

A 

administrator password 76 

always install 17 

application module 139 

application modules 28–32 

ImageUltra Builder 14–15 

audio driver 

ImageUltra Builder 14 

auditboot 16 

B 

base map settings 75–81 

base maps 15, 81 

creating 66–81 

defined 9, 66 

defined in ImageUltra Builder 15 

base operating system hardware specific modules 48–54 

base operating system modules 


base-partition module 78 

Before/After Menu Options tab 

base map settings 77 

behavior 16 

BIOS 14 

C 

CHKDSK 15 

color settings 80 

compressed module source 15 

computer name 76 

container 41 


ImageUltra Builder 14–15 

core chip set 12 

custom modules 26–28 

D 

DeployCenter 1–2, 10, 14, 47–48, 54, 57, 62, 93–95, 

112, 116, 130 

ImageCenter 93 

overview 93 

deploying images 83–93 

deployment methods 88–93 

CD distribution 88 

network deployment 90 

deployment repository 


device driver modules 10, 32–38, 82 


DHCP configuration 76 

direct-network install 

network options tab 79 

DOS window 15 

DOS-based programs 14 

Drive Image 132 

driver map 15, 17 

create 81 

defined 15, 67 

driver map filter 83 

driver map settings 82–83 

E 

EEPROM 14 

F 

file extensions 

.BMA 15 

.CRI 15 

.DMA 15 

.IMZ 15 

filter/utility modules 38–39 

filters 




first boot 17 

G 

gateway 76 

general tab 


driver map settings 82 

Ghost 2, 10, 13–14, 48, 57, 129–130, 132 

considerations 129 

gold 47 

H 

Hardware Independent Imaging Technology 

behavior 17 

defined 10 

enabled 10, 82 

integration 13 

hardware-specific image 10–11, 13, 82 

Hidden Protected Area 10, 82 

HIIT 

See Hardware Independent Imaging Technology 

HIIT-enabled 13 

HPA 

See Hidden Protected Area 

I 

IBM Customization Program 55–56 

IBM PCs 11 

IBM Preload modules 22–26 


IBM service partition 126 

IBM ThinkPad 14 

ignore HIIT processing 17 

image cleanup tab 


image maintenance 


image types 10–11 

hardware-specific image 10 

portable-sysprep image 10 

selecting the best for you 11–13 

ultra-portable 10 


image-cloning software 11 

image-cloning tool 10 

ImageUltra Builder ??–143 

application modules 28–32 

base map settings 75–81 

base maps 


defined 9, 15, 66 

base operating system hardware specific modules 

48–54 

container 14 

core chip set 12 

custom modules 26–28 

deploying images 83–93 

deployment methods 88–93 

CD distribution 88 

network deployment 90 

deployment repository 15 

device driver modules 32–38 

driver map 

create 81 


driver map settings 82–83 

filter/utility modules 38–39 

filters 15 

defined 14 

Hardware Independent Imaging Technology 

defined 10 

integration 13 


IBM Preload modules 22–26 

image maintenance 13 

image portability 12–13 

image types 10–11 


portable-sysprep image 10 

selecting the best for you 11–13 

ultra-portable 10 

installation time 13 

InstallShield 27 

map settings 

Base map 75 

Driver map 82 

module 

catagories 13 

defined 9 

modules 


application 14–15 

base operating system 13 

container 15 

defined 14 

device driver 14 

operating system 13 

operating system add-on 13 

partitioning 13, 15 

network-staging folder 91 

operating system add-on modules 39–47 

partitioning modules 47–48 

portable-sysprep image 12–13 

creating 55 

repository 15 


defined 9, 15 

file extensions 15 

Smart Image 3, 9, 11, 26 


definition 9 

Sysprep 10 

suported operating systems 13 

supported hardware 13 

system board 12 

ultra-portable image 12–13 

utilities 

defined 15 

Windows 2000 images 13 

Windows Installer 26 

Windows XP images 13 

INF installable 17 

INF installs 17 

install sequence tab 


install slot 17 

installation time 


InstallShield 27 

IP address 76 

K 

keyboard settings 80 

L 

layout settings 80 

M 

map settings 

Base map 75 

Driver map 82 

menu appearance tab 


color settings 80 

keyboard settings 80 

layout settings 80 

menu driven area 15 

menu items 81 

metadata 15

Microsoft Sysprep 11, 56 

module behavior 70 

module categories 


modules 

application 28–32 

base operating system hardware specific 48–54 

custom 26–28 

defined 9 

device driver 32–38 

filter/utility 38–39 

IBM Preload 22–26 

operating system add-on 39–47 

partitioning 47–48 

msiexec.exe 26 

My Computer 15 

N 

Network Boot 95 

network options tab 


driver map settings 82 

network synchronization 69 

network options tab 79 

network-staging folder 91 

normal device detection 17 

O 

operating system add-on modules 39–47 


operating system modules 13, 42 


organization name 77 

OS modules 140 

P 

partition tab 


partitioning modules 47–48 

ImageUltra Builder 13, 15 

portable-sysprep image 10–13, 55, 82 

creating 55 

PowerCast 94, 115, 117, 120–121 

PowerCasting 94 

overview 94 

PowerQuest 

Drive Image 132 

Pre-boot Execution Environment 95–96, 100, 107 

capture donor image 95 

PXE 

See Pre-boot Execution Environment 

R 

read only memory (ROM) 14 

Redbooks Web site 148 

Contact us viii 

relative location 17 

repository 


defined 15 


file extensions 15 


Rescue and Recovery 81 

S 

script files 46 

service partition 82, 129 

SETUP.ISS 28, 122 

generate 28 

silent install command 16, 45 

silent installation 26 

defined 26 

Smart Image 3, 9, 11, 26, 79, 82–83, 91 


definition 9 

Sysprep 10 

Software Delivery Assistant 

with ImageUltra Builder 122–128 

SoundMAX audio driver 32, 37 

source directory 45 

subnet mask 77 

supported hardware 


supported operating systems 


Symantec 

DeployCenter 1–2, 10, 13–14, 47–48, 54, 57, 62, 

93–95, 112, 116, 130 


overview 93 

Ghost 2, 10, 13–14, 48, 57, 129–130, 132 

considerations 129 

Sysprep 76 

Sysprep tool 11 

system board 12 

System Migration Assistant 

with ImageUltra Builder 121 

T 

target location 16 

ThinkCentre 14 

ThinkPad 11 

tree structure 67 

U 

ultra-portable image 10–13, 82 

ultra-portable module 140 

ultra-portable system 140 

unattended installation 

defined 26 

user information tab 


utilities 63 


Index 151

V 

VBE 

See Virtual Boot Environment 

video driver 


Virtual Boot Diskette 95 

create 105 

Virtual Boot Environment 94–95 

W 

Web-D 

with ImageUltra Builder 121 

Windows 2000 

ImageUltra Builder 8, 14, 56 

Service Pack 4 


Windows 2000 images 13 

Windows Installer 26 

Windows NT 4.0 Resource Kit Support Tools 56 

Windows XP 

ImageUltra Builder 8, 56 

Windows XP images 13 

WinRAR 28, 138 

workgroup 76 


ThinkVantage 

Technologies: 

Using ImageUltra Builder 

Overview of 



installation 

Customization and 

usage 

Back cover 

ThinkVantage Technologies brings your IBM PCs one step closer 

to being self-configured, self-optimizing, self-protecting, or 

self-healing to help save you time and money throughout the life 

of your systems. In short, ThinkVantage Technologies let you 

focus your attention on your business, rather than on your 

computer. 

ThinkVantage Technologies are software tools designed to help 

customers drive down IT support costs (in particular, the cost of 

a PC in managing and supporting systems after its initial 

purchase), increase security and decrease the complexity of 

todayís IT infrastructure. 

This Redpaper will help you install, tailor and configure the IBM 

ImageUltra Bulider ThinkVantage Technology. 

INTERNATIONAL 

TECHNICAL 

SUPPORT 

ORGANIZATION 

® 

Redpaper 

BUILDING TECHNICAL 

INFORMATION BASED ON 

PRACTICAL EXPERIENCE 

IBM Redbooks are developed 

by the IBM International 

Technical Support 

Organization. Experts from 

IBM, Customers and Partners 

from around the world create 

timely technical information 

based on realistic scenarios. 

Specific recommendations 

are provided to help you 

implement IT solutions more 

effectively in your 

environment. 

For more information: 

ibm.com/redbooks

Using ImageUltra Builder - IBM Redbooks

Create successful ePaper yourself

Delete template?

Save as template?