IBM REDP-4372-00 User Manual

Draft Document for Review November 15, 2007 3:27 pm REDP-4372-00

Front cover

Tivoli Provisioning Manager
for OS Deployment
in a Retail Environment

Specifically catered for IT professionals
working in the retail industry

Describes frequently used
scenarios

Cookbook for getting
started

ibm.com/redbooks

Vasfi Gucer

Leif Egeholm Nielsen

David Kwock

John Hardegree

Redpaper

Draft Document for Review November 15, 2007 3:27 pm 4372edno.fm

International Technical Support Organization

Tivoli Provisioning Manager for OS Deployment in a
Retail Environment

January 2008

REDP-4372-00

4372edno.fm Draft Document for Review November 15, 2007 3:27 pm

Note: Before using this information and the product it supports, read the information in

“Notices” on page vii.

First Edition (January 2008)

This edition applies to Tivoli Provisioning Manager for OS Deployment Version 5.1 Fixpack 3.

This document created or updated on November 15, 2007.

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

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

Draft Document for Review November 15, 2007 3:27 pm 4372TOC.fm

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix

The team that wrote this paper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Target audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Definition of roles and skills. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 The retail environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 The role and importance of IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Operating systems on Point-of-sale devices . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Introducing Tivoli Provisioning Manager for OS Deployment . . . . . . . . . . . 6

1.6 Tivoli Provisioning Manager for OS Deployment in retail environments . . . 8

1.7 Typical scenarios in a system life cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.7.1 First-time installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.7.2 Preparing a system for use as a master image. . . . . . . . . . . . . . . . . 11

1.7.3 Deploying to multiple systems from a master image. . . . . . . . . . . . . 12

1.7.4 Re-deploying to a specific system to resolve a problem. . . . . . . . . . 12

1.7.5 Backing up and restoring an entire system to resolve a problem . . . 13

1.8 Introducing the LAB environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2. First-time installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Creating an unattended profile for Windows XP . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Copying the media files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.2 Slipstream Windows XP Service Pack 2. . . . . . . . . . . . . . . . . . . . . . 20

2.2.3 Creating the unattended profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Adding drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3.1 Downloading and unpacking the drivers . . . . . . . . . . . . . . . . . . . . . . 32

2.3.2 Creating a software package for device drivers . . . . . . . . . . . . . . . . 36

2.4 Deploying to a pristine system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.4.1 Creating a deployment scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.4.2 Modifying the unattended profile for a dynamic host name. . . . . . . . 48

2.4.3 Client Machine Boot and Deploy. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

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

4372TOC.fm Draft Document for Review November 15, 2007 3:27 pm

Chapter 3. Mass-Distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.1 Creating a cloned profile for Windows XP. . . . . . . . . . . . . . . . . . . . . . . . . 56

3.1.1 Preparing the donor system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.1.2 Capturing the system image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.1.3 Configuring the system profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.2 Adding support for different hardware types . . . . . . . . . . . . . . . . . . . . . . . 69

3.2.1 The principle of device driver injection . . . . . . . . . . . . . . . . . . . . . . . 71

3.2.2 Software Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.2.3 Deployment Scheme Parameter Wizard. . . . . . . . . . . . . . . . . . . . . . 72

3.3 Deploying the XP cloning profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Chapter 4. Redeployment scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.1 Reasons for redeployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.2 Redeployment from the local hard drive . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.2.1 Create a deployment scheme that supports redeployment. . . . . . . . 86

4.2.2 Create a boot menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.2.3 Process for local redeployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.3 Redeployment from the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.3.1 Redeployment Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Chapter 5. System image snapshots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.1 Introducing the POS plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.2 Installing the POS plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.2.1 Obtaining the POS package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.2.2 Installing the POS plug-in from the Windows GUI . . . . . . . . . . . . . . 98

5.2.3 Installing the POS plug-in from the command line . . . . . . . . . . . . . 100

5.2.4 Verifying the POS plug-in installation . . . . . . . . . . . . . . . . . . . . . . . 101

5.3 Remotely controlling POS terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.3.1 Wake on LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.3.2 Power off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.4 Creating Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.4.1 Performing a POS terminal backup. . . . . . . . . . . . . . . . . . . . . . . . . 105

5.4.2 Managing the list of backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.4.3 Restoring a POS backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.5 Switching hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Chapter 6. Real world deployment scenarios. . . . . . . . . . . . . . . . . . . . . . 125

6.1 Large environment considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.1.1 Managing development and production environments . . . . . . . . . . 126

6.1.2 Expanding from one to multiple servers . . . . . . . . . . . . . . . . . . . . . 127

6.2 Replicating software and configurations . . . . . . . . . . . . . . . . . . . . . . . . . 127

6.2.1 Built-in file replication service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.2.2 Command line method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.2.3 Profile migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

iv Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372TOC.fm

6.3 Network Bandwidth Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.3.1 Unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.3.2 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.3.3 Multicast with synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Appendix A. Alternate boot sequence on POS systems. . . . . . . . . . . . . 133

When to boot from hard drive and from network . . . . . . . . . . . . . . . . . . . . . . 134

Forcing a POS system to boot into PXE mode . . . . . . . . . . . . . . . . . . . . . . . 134

Preparing alternate boot sequence for Wake on LAN . . . . . . . . . . . . . . . . . . 135

Appendix B. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

System requirements for downloading the Web material . . . . . . . . . . . . . 138

How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

How to get Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Contents v

4372TOC.fm Draft Document for Review November 15, 2007 3:27 pm

vi Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372spec.fm

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

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

4372spec.fm Draft Document for Review November 15, 2007 3:27 pm

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

Redbooks (logo) ®
DB2®
IBM®

The following terms are trademarks of other companies:

Snapshot, and the Network Appliance logo are trademarks or registered trademarks of Network Appliance,
Inc. in the U.S. and other countries.

Java, JDBC, Ultra, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United
States, other countries, or both.

Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.

i386, Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of
Intel Corporation or its subsidiaries in the United States, other countries, or both.

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

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

NetView®
Redbooks®
SurePOS™

Tivoli Enterprise™
Tivoli®

viii Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372pref.fm

Preface

Retail environments, like many other industries, are continously seeking ways to
reduce costs and improve their competitive advantages.

One area where cost reduction is at play is with the IT deployed in the
warehouses. Because this environment is so distributed, significant cost savings
can be achieved if the hardware and software can be maintained without having
to be physically present in the warehouse.

This IBM® Redpaper presents the IBM Tivoli Provisioning Manager for OS
Deployment software product as a solution to help customers reduce costs for
deploying operating systems to point-of-sale devices in a highly distributed
environment.

Additionally, the Redpaper introduces a solution specifically developed for IBM
Technical Support, to reduce the recovery time whenever a software or hardware
failure requires a system to be re-deployed.

The audience of the Redpaper are IT managers in the retail sector and technical
support people in areas with point-of-sale or kiosk systems. Technical support
people in other highly distributed environments may also benefit from the
information herein.

The team that wrote this paper

This paper was produced by a team of specialists from around the world working
at the International Technical Support Organization, Austin Center.

Vasfi Gucer is an IBM Certified Consultant IT Specialist at the ITSO Austin
Center. He started his IBM career as a Network Specialist in 1989.. He has over
18 years of experience providing technical support across a variety of IBM
products and technologies, including communications, network and systems
management. For the last ten years Vasfi has been working for IBM ITSO, where
he has been writing IBM Redbooks® and creating and teaching workshops
around the world on a variety of topics. In this position, he has also worked on
various Tivoli® customer projects as a Systems Architect and Consultant. He
holds a Master’s degree in Engineering.

Leif Egeholm Nielsen is a Certified IT Architect in Operations Architecture at
IBM Denmark. He currently holds a position as account architect for the

© Copyright IBM Corp. 2008. All rights reserved. ix

4372pref.fm Draft Document for Review November 15, 2007 3:27 pm

Carlsberg account. He has 15 years of experience in the IT business and 10
years with Tivoli and Software Distribution. He holds a bachelor degree in
mechanical engineering. Leifs areas of expertise include operational
architectures, systems management, software distribution, and Tivoli software.
Leif has previously participated in several ITSO residencies related to IBM Tivoli
Inventory and Software Distribution products.

David Kwock is an IT Specialist in the United States. He has 7 years of
experience in IT Service Management field. He has worked at IBM for 1 year. His
areas of expertise include business automation, Service Oriented Architecture,
System P and Linux®. He has written extensively on IT Service Management
and Service Oriented Architecture. David has also spoken at IBM Executive
Summits and Gartner conferences on the topics of IBM Service Management
and Service Oriented Architecture.

John Hardegree is a senior IT Specialist working for IBM Global Services in the
US. He has worked with Tivoli products since 1993 and was Tivoli Enterprise™
Certified in 1999. John holds a degree in A.S Degree in Electronics Technology
and has over twenty years of experience in software/firmware design and
systems management technical support. He spent almost four years with an IBM
business partner as a Tivoli Professional Services consultant, has developed and
taught several Tivoli courses and was the author of the TME10 List FAQ. He
currently works on the midrange monitoring team for the State of Texas account.

Thanks to the following people for their contributions to this project:

Wade Wallace
International Technical Support Organization, Austin Center

Wayne Correa, Portfolio Manager, Retail Industry
IBM Global Services, North Carolina, USA

David H. Fritz
Global Technology Services
Technology and Business Integration, IBM Austin

x Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372pref.fm

Become a published author

Join us for a two- to six-week residency program! Help write a book dealing with
specific products or solutions, while getting hands-on experience with
leading-edge technologies. You will have the opportunity to team with IBM
technical professionals, Business Partners, and Clients.

Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you will 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 paper or other IBM Redbooks in one of the following ways:

򐂰 Use the online Contact us review Redbooks form found at:

ibm.com/redbooks

򐂰 Send your comments in an e-mail to:

[e-mail]

򐂰 Mail your comments to:

IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

Preface xi

4372pref.fm Draft Document for Review November 15, 2007 3:27 pm

xii Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch01.fm

1

Chapter 1. Introduction

This chapter introduces the retail environment, the technical challenges retail
environments pose and how Tivoli Provisioning Manager for OS Deployment can
be used to solve some of them.

This chapter also introduces realistic POS provisioning scenarios and outlines
the environment used to produce this paper.

Readers already familiar with the retail environment may skip most of this
chapter but for a full understanding of the scenarios it is recommended you read
sections 1.7, “Typical scenarios in a system life cycle” on page 10 and 1.8,
“Introducing the LAB environment” on page 13.

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

4372ch01.fm Draft Document for Review November 15, 2007 3:27 pm

1.1 Target audience

This Redpaper is written specifically with IT people who work in the retail sector
in mind. However, many of the topics and scenarios can easily be mapped to
traditional workstation environments and therefore also be of benefit to IT
professionals working with OS deployments outside the retail environments.

Since most of the content is technical in nature, a minimum of technical
understanding is required. Experience with automated deployment of operating
systems is highly recommended but not required. Understanding the principles
involved in automated software distribution will be helpful.

Note: This Redpaper is based on Tivoli Provisioning Manager for OS
Deployment V5.1 with Fixpack 3. Some of the screenshots may look slightly
different from the ones in previous ITSO publications because of this.

1.1.1 Definition of roles and skills

Throughout the scenarios and examples the following defintions are used for
different roles.

򐂰 POS user - or simply end user

The POS user refers to the person using the POS system. For a cash register
this will be the cashier, for self-checkout systems or kiosks this will be a
customer. It is not assumed that the POS user will have any IT skills as such
and normally this person will not be involved in any processes except
experiencing a problem and notify someone of the problem.

򐂰 Local super user - or simply super user

Every store, warehouse or super market should have at least one person to
fulfill this role. The super user is not an IT professional, but has some
understanding about the underlying IT and is capable of communicating with
the IT professionals in helpdesk etc.

򐂰 Central IT

Central IT refers the IT professionals located centrally at one location,
physically distant from the production POS systems. There is no distinction in
this Redpaper between IT professional at the helpdesk, server support,
development etc.

򐂰 Field Technician

2 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch01.fm

This role covers an external IT professional that is called in to a store to
perform on-site repairs of systems. This include a service technician from IBM
Technical Support.

1.2 The retail environment

The retail environment comprises every type of store, from the apparel store with
one or two cash registers, to a large super market chain with thousands of stores
each having a variety of cash registers, self-checkout lanes and kiosk systems
for various purposes.

A typical IT environment for a department store is shown in Figure 1-1 on page 4.

The main application servers are located in a data center, most likely with a
redundant setup, possibly even made site-redundant. This is the backend system
for all transactions and will normally have interfaces to other systems used for
logistics, finance, payroll, ordering and so forth.

In each warehouse is a local server that handles transactions from POS systems
and forwards the transactions to the central server. This setup enables a
warehouse to continue operation even if the network connections are interrupted
for shorter periods of time. Typically, this server is also used for local
customizations such as the text on the printed receipts, local discounts etc.
Larger warehouses will probaly have this system setup in a redundant
configuration. Even if the applications are configured to use the central server in
case the local server is unavailable, there may be performance requirements that
justify such setup.

Alone in the area of providing a high level of availability for the application servers
required for purchase transactions lies several technical challenges. These are
mainly part of the network, servers and applications and are not the scope of this
Redpaper. Much of this information can be found from other sources, including
the IBM Redbook Enabling the On Demand Store with IBM Store Integration
Framework, SG24-6698.

Chapter 1. Introduction 3

4372ch01.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 1-1 A typical IT environment for a department store

IBM POS systems are very much like standard Intel®-based workstations. There
is a motherboard with an Intel x86 processor, memory, graphics adapter and
network interface card. In addition there is also one or more USB interfaces.
However, there are also some diferences: A POS system typically has several
peripheral devices attached, including but not limited to;

򐂰 A keyboard, specifically designed for the point-of-sale system
򐂰 A touch screen
򐂰 A barcode scanner
򐂰 A scale
򐂰 A sensor (to verify the customer puts the item in the bag)
򐂰 A credit-card reader with signature type pad or pin code keyboard
򐂰 A cash-drawer
򐂰 A printer for receipts

4 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch01.fm

These peripherals are connected via special connectors and via USB interfaces
which may be carrying the standard 5 Volts or powered USB with 12 or 24 Volts.

The system typically runs only one application which is developed and/or tailored
specifically to serve the purpose of the system. Under normal operation the end
user will only use the application and not think about or have access to the
underlying operating system.

By separating the point-of-sales systems from any traditional workstations in a
store it is possible to limit the risk of infecting the point-of-sales systems with
viruses, worms and other malware. The separation is done using VLANs, routers
and/or firewalls depending on the required security level.

The retail environment is highly distributed, especially large retail chains, which
may have one or more data centers and a significant number of stores distributed
across the country or the world. The IT skills in a store is limited, resulting in a
strong focus on standardization and on remote managability.

The typical lifetime of a point-of-sale system is five to seven years, which is
somewhat more than a normal office workstation, be it a desktop or a notepad.
During the lifetime of a point-of-sale system, the operating system is unlikely to
change more than one or two times. Applications may be updated one or two
times a year.

1.3 The role and importance of IT

For any store or warehouse, the point-of-sale system is essential for business.
This is where goods are exchanged for money. Without the capability to handle
these transactions automatically, a significant amount of back-office work is
required and some parts of the transactions may not even be possible, such as
payments by use of credit cards and printing out receipts.

It’s easy to visualize what happens if a store suddenly has a limited capability of
processing sales: The remaining lanes will have growing queues, causing
reduced customer satisfaction, and if the situation happens more than once in a
quarter, some customers will probably place their business elsewhere.

For this reason, most larger warehouses have several layers of redundancy. First
of all, there are usually more lanes than needed except for hollidays and
seasonal occasions. Additionally, the network is typically kept isolated from
networks used by regular workstations, and made redundant so half the POS
systems are connected to one swtich and the other half to another. Application
servers should also be set up for high availability, both with respect to
independency in an individual store, and with the capability to fail over to a

Chapter 1. Introduction 5

4372ch01.fm Draft Document for Review November 15, 2007 3:27 pm

centrally located application server if the local application server fails. There are
many wariations possible, however, they are not the topic for this Redpaper.

It is important to note that most larger warehouses have a surplus of POS
systems which reduces the effects of one or a few systems being out of order.
Smaller stores or restaurants are more likely to be affected, even if one system is
out of order, since they may only have a total of two or three POS systems.

1.4 Operating systems on Point-of-sale devices

Not all operating systems are suitable for point-of-sales devices. A typical POS
system has a lot of special devices that require drivers which are not widely
available on all platforms. Also, the IT department may want to prevent the user
from getting access to anything but the POS application which require an
operating system with lockdown features.

The most common operating systems for point-of-sale systems include, but are
not limited to:

򐂰 Microsoft® Windows® XP Professional
򐂰 Microsoft Windows 2000 Workstation
򐂰 WEPOS; Microsoft Windows Embedded for Point-of-services
򐂰 IRES; IBM Retail Environment for Suse Linux for POS

Different distributions of Linux also exist.

Older environments may also include systems running PC-DOS 2000.

For the scenarios used throughout this Redpaper we will only use Windows XP.
For information about deploying Windows 2000 and Linux, please consult the
IBM RedBook Deployment Guide Series: Tivoli Provisioning Manager for OS
Deployment V5.1, SG24-7397.

1.5 Introducing Tivoli Provisioning Manager for OS Deployment

The IBM Tivoli software products that have previously provided capabilities for
installation of operating systems on bare metal systems include NetView®
Distribution Manager and Tivoli Configuration Manager. These products have
been suceeded by the IBM Tivoli Provisioning Manager product which natively
does not include similar features.

6 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch01.fm

In 2006, IBM purchased a Swiss company called Rembo Technology SaRL. With
this, IBM also acquired the Rembo software products to fill in this gap; Rembo
Toolkit and Rembo Auto-Deploy.

The Rembo Toolkit was added to Tivoli Provisioning Manager v5.1 to provide
native image management. The Rembo Auto-Deploy product was rebranded to
Tivoli Provisioning Manager for OS Deployment.

Tivoli Provisioning Manager for OS Deployment is a software product that
provides image management. It captures images of systems which have been
prepared for mass-distribution, provides various ways of customizing and
adjusting these images and provides a mechanism for distributing them to
multiple systems.

During the distribution of an image, Tivoli Provisioning Manager for OS
Deployment can identify the target system and automatically inject drivers that
fits the particular system. A captured image can therefore be used for distribution
to different hardware platforms. These processes are described in Figure 1-2 on
page 8, which also clarifies some of the definitions used throughout the book:

򐂰 Unattended profile

Profile is the term used for an element containing an operating system that
can be deployed. An unattended profile means the operating system is based
on the original installation files and the deployment will perform a true
installation, going through all the steps a normal installation would, but using
a script to automate all or most of the process.

򐂰 Cloning profile

A profile is the term used for an element containing an operating system that
can be deployed. A cloning profile means the operating system is based on
an already installed system that has been prepared for mass distributions
(cloning). For performance reasons this is the most often used method for
mass distributions.

򐂰 Software Package

This must not be confused with software packages as defined in other
software distribution products such as IBM Tivoli Configuration Manager. In
Tivoli Provisioning Manager for OS Deployment a software package can only
be deployed as part of the deployment of an operating system in either an
unattended or a cloning profile. A software package typically contains
additional device drivers or files that need to be copied to the target, optionally
executing a batch script or an executable file as part of it. Software packages
can also be used to run unattended installations using MSI software
packages.

򐂰 Deployment Schemes

Chapter 1. Introduction 7

4372ch01.fm Draft Document for Review November 15, 2007 3:27 pm

The deployment of a profile can be customized using a deployment scheme.
The default deployment scheme will be suficient for most deployments, but in
some cases there may be reasons to adjust the deployment to optimize
network bandwidth.

򐂰 Configuration

Every profile has a configuration, which includes the attributes to apply when
deploying the profile.

Figure 1-2 The main processes for a Windows XP mass distribution

1.6 Tivoli Provisioning Manager for OS Deployment in retail environments

From an architectural point of view, a point-of-sale system consist of different
layers of software. This is illustrated in Figure 1-3 on page 9. With Tivoli

8 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch01.fm

Provisioning Manager for OS Deployment it is possible to maintain the
deployment and re-deployment of Operating System with suitable drivers, a
Java™ Runtime environment and the applications to run directly on the operating
system or on top of the Java Runtime environment. The applications should in
this case be considered static, that is; the application will not during deployment
receive any modifications to reflect the specific system it is installed to.

Data updated at regular intervals, including for example weekly or daily pricelists
or special content to print on receipts, are not suitable for deployment via Tivoli
Provisioning Manager for OS Deployment. This would require frequent, perhaps
weekly updates to the image. Instead, this should be automated using other
systems or scripts (which may be part of the static data that can be deployed
using Tivoli Provisioning Manager for OS Deployment).

Realtime dynamic data consist mainly of transactions. For obvious reasons,
these should never be of concern to a specific point-of-sale system. Transactions
should always be handled by an enterprise application server with capabilities to
perform roll back and roll forward, and preferably be based on a messaging
system between POS systems and transaction servers.

Figure 1-3 Software on a POS system from an architectural point of view

Chapter 1. Introduction 9

4372ch01.fm Draft Document for Review November 15, 2007 3:27 pm

1.7 Typical scenarios in a system life cycle

Much has been written about the system life cycle. Figure 1-4 on page 10 shows
some of the elements that are part of the system life cycle. Some of these
elements can be supported using the Tivoli Provisioning Manager for OS
Deployment product while others will require additional software, tools and
processes.

Figure 1-4 POS System Lifecycle

The remaining chapters of this paper will, through selected scenarios, show how
the Tivoli Provisioning Manager for OS Deployment product can be used to
accomodate the following system life cycle tasks that are carried out at regular
intervals in any retail environment;

򐂰 First time installations using unattended installation
򐂰 Preparing a master image for mass distribution
򐂰 Deploying to multiple systems from a master image
򐂰 Re-deploying to a specific system to resolve a problem
򐂰 Backing up and restoring an entire system to resolve a problem

10 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch01.fm

1.7.1 First-time installations

There are typically three situations where a first-time installation is required: One
is when the initial environment is being established and another is when a
solution already exists, but the current hardware is being replaced with new.
These are commons situations in any IT environment and both cases can
generally be managed in the same way. The third situation is when a new
operating system is introduced, such as a change from Microsoft Windows to
Linux, or an upgrade from Windows to Vista.

In a traditional IT department with PCs, the obvious approach may be to insert
the CD with the operating system and proceed from there. However, there are
some pitfalls with this method in the retail environment:

򐂰 Normally the point-of-service system does not have built-in floppy or CD-ROM

drives. This can of course easily be fixed in the IT department via a
USB-attached CD-ROM drive, but it does require some additional work.

򐂰 Some of the systems require specific hardware drivers to be installed during

the operating system installation. This requires modifications of the default
installation media or network drive.

򐂰 Without any additional automation method this approach will not be very

practical with hundreds or thousands of POS systems in the production
environment.

This is where Tivoli Provisioning Manager for OS Deployment comes at play.
Adding a new hardware driver to an existing operating system is simply a matter
of downloading the driver from the provider, unpack and create a software
package with the drivers. Then the system is ready for initial deployment.

1.7.2 Preparing a system for use as a master image

Once a system has been prepared with the correct drivers and optionally had
one or more applications installed and configured on it, it is ready to serve as a
master image.

Before the system can be captured as an image, a final set af tasks must first be
completed. For a Windows system this typically includes some cleanup and
deletion of user-specific data, followed by a special utility called sysprep, which
prepares the system for mass-distribution. The sysprep is the very last step to
complete because it includes shutting down the system in a special state that is
intended for mass distribution.

On Linux systems, there are similar cleanup activities but no special utilities to
prepare the system for mass-distribution.

Chapter 1. Introduction 11

4372ch01.fm Draft Document for Review November 15, 2007 3:27 pm

Once the installation has been prepared, the system must be booted from the
network and connect to the Tivoli Provisioning Manager for OS Deployment
server, From here, the installation can be used to create a new profile.

1.7.3 Deploying to multiple systems from a master image

Once the profile is on the Tivoli Provisioning Manager for OS Deployment server
and necessary additional adjustments, scripts and drivers have been added, it is
ready for deployment to other systems.

Without any further changes, the master image can be used for deployments to
systems with same hardware. In order to distribute to systems with other
hardware, it may be necessary to inject new drivers. This is done by defining
software packages with the drivers and define bindings or rules for which drivers
to inject on which systems.

1.7.4 Re-deploying to a specific system to resolve a problem

Normally if a software or hardware related problem occurs, the IT organization
will attempt to troubleshoot and fix the problem. This can be a time consuming
effort. The retail environment varys significantly from the traditional office
environments where PCs are used for administrative tasks. Imagine a small
super market or store with three or four cash registers. If one POS station is not
available during busy hours, the line of customers could quickly grow, resulting in
unhappy customers and eventually loss of business when disgruntled customers
leave the store without making their purchases.

For the retail environment, it is therefore imperative that a failed system be
brought back into operation as quickly as possible. Tivoli Provisioning Manager
for OS Deployment provides several tools to assist in doing this, depending on
the particular situation:

򐂰 If the failure is a local software error, the quickest way to get a system back

online is a local redeployment. This feature requires that a copy of the
installed image exist in a hidden partition on the hard drive, and that any local
dynamic data can be automatically retrieved from a central server after
redeployment.

򐂰 If the failure is the result of a malfunctioning hard drive, and a replacement

drive is quickly installed, a new operating system can be deployed from a
local Tivoli Provisioning Manager for OS Deployment server within 20-30
minutes. As in the previous case any dynamic data will need to be recovered
or recreated after OS redeployment.

12 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch01.fm

1.7.5 Backing up and restoring an entire system to resolve a problem

If the system contains dynamic data, a new POS plug-in utility for the Tivoli
Provisioning Manager for OS Deployment product can be used to create
image-backups of individual systems for faster restores. Obviously a restore can
only recover the data that were included in the backup. If the dynamic data are
weekly or daily price updates this should be managed by running daily backups.

The POS plug-in will be covered in Chapter 5, “System image snapshots” on
page 95.

1.8 Introducing the LAB environment

In order to test realistic scenarios, a small environment has been established for
the production of this Redpaper. The systems used throughout the scenarios are
depicted in Figure 1-5 on page 13.

Figure 1-5 The LAB environment used for this Redpaper

The environment consist of two Intel based servers running Microsoft Windows
2003 Server and Tivoli Provisioning Manager for OS Deployment. One (BERLIN)
represents a development and testing environment, while the other (NICE) is
used to represent a production environment in a store. There is also an

Chapter 1. Introduction 13

4372ch01.fm Draft Document for Review November 15, 2007 3:27 pm

additiononal server (not shown) that provides DHCP services to our simulated
environment.

Four types of POS devices exist in the simulated environment as well, each of
which is a unique model, which helps to demonstrate Tivoli Provisioning
Manager for OS Deployment’s capability of identifying different types of hardware
and injecting the right drivers for each. In a large super market, for instance, it
would not be unrealistic to have different types of hardware performing the same
functions. The IT department would then typically have at least one of each
hardware type.

The real-world IT environment that we are trying to simulate with the lab
environment is depicted in Figure 1-6 on page 15.

Note that the environment does not include any application servers or other
management systems. There would most likely be at least one application server
in each warehouse, and several centrally located application servers in an actual
enterprise, but management of these servers falls outside the scope of this
paper. Likewise, there would normally be servers for systems management, such
as monitoring and remote administration, but these are also outside our scope.

14 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch01.fm

Figure 1-6 A real-world retail IT environment

Chapter 1. Introduction 15

4372ch01.fm Draft Document for Review November 15, 2007 3:27 pm

16 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

2

Chapter 2. First-time installations

In this chapter we discuss and describe how we install the Windows XP
Professional operating system in the point-of-sale environment. We include
step-by-step instructions for getting bare metal working for Windows XP systems.

We cover the case of a point-of-sale terminal build in a retail environment, where
we may also have to consider special hardware configurations specific to the IBM
SurePOS™ terminals.

This chapter has the following topics:

򐂰 Introduction
򐂰 Creating an unattended profile for Windows XP
򐂰 Creating software packages for drivers that need to be injected

© Copyright IBM Corp. 2008. All rights reserved. 17

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

2.1 Introduction

The first step is to choose what to deploy. With Tivoli Provisioning Manager for
OS Deployment, you can either clone a machine or you can create an
unattended setup profile. The former option copies the operating system together
with the installed software from a source machine to a destination machine. The
latter performs an automatic installation of an operating system as though you
are at the machine with the installation CDs.

We start this chapter with the steps to perform an unattended installation of a
Windows XP profile with some associated device drivers that will be deployed on
a bare metal machine. This scenario is most likely the way a retail’s IT
organization would start their automated deployment of terminals unless they
already had a template image suitable for cloning. Next, we describe the cloning
process of a Windows XP machine and the customization process of the
captured image to prepare for the mass deployment of the clone.

For both the unattended set up and the cloning deployments, we use Windows
XP, Service Pack 2. In terms of Tivoli Provisioning Manager for OS Deployment
we will do the following

򐂰 Create an unattended Windows XP installation profile using Windows XP SP2

installation CDs

򐂰 Clone a machine having the Windows XP operating system

For a target machine, we are using several different IBM SurePOS system types.
They all meet the following minimum requirements listed below:

򐂰 PXE-compliant bootrom, version 2.00 or higher
򐂰 Minimal CPU: PentiumR type level
򐂰 Minimal RAM memory: 128 MB
򐂰 Video Electronics Standarts Association (VESA) release 2.0 or later,

compliant Video BIOS to get high resolution (VGA fallback is always possible
in case of incompatibility). However, Tivoli Provisioning Manager for OS
Deployment can also work on machines without a monitor attached.

򐂰 Either a traditional Advanced Technology Attachment (ATA) drive with Ultra™

Direct Memory access (DMA) support if speed is required or any
BIOS-supported hard drive.

򐂰 Desktop Management Interface (DMI) support for collecting hardware

information, such as model and serial number.

The machines we used had at least 8 GB of diskspace since the Windows XP
installation and the hidden partition used by Tivoli Provisioning Manager for OS

18 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Deployment during the deploy may have problems with hard disk of lower
capacity.

2.2 Creating an unattended profile for Windows XP

In this section we describe how to create a profile for unattended installation of
Windows XP Professional with Service Pack 2 included. The major steps to
create this profile includes:

򐂰 Copy the \i386 directory from the original installation media
򐂰 Download and slipstream the service pack
򐂰 Create the profile in Tivoli Provisioning Manager for OS Deployment

2.2.1 Copying the media files

Copying the media files from the CD/DVD to a local disk allows us to customize
the source depot for our installation of Windows XP. In our scenario we are using
a Windows XP Professional CD for an Intel based 32-bit system.

1. Copy the full i386 folder from the CD-ROM drive including all system and
hidden files as shown in Example 2-1. If you decide to copy using the GUI,
make sure all hidden and system files are shown, otherwise thse fiels will not
be copied.

Example 2-1 Copying the Windows XP installation files to a local drive

xcopy /E /H D:\i386 X:\WinXPimg\i386

2. Verify all files and folders are created in target folder as shown in Figure 2-1
on page 20.

Chapter 2. First-time installations 19

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-1 Files sucessfully copied from CD-ROM to target destination

2.2.2 Slipstream Windows XP Service Pack 2

Slipstreaming a service pack, is the process of integrating the service pack into
the installation so that with every new installation the operating system and
service pack are installed at the same time. It not only has the advantage that
when you install your operating system you don’t have to apply the service pack,
but also later, if you update any windows component, you will be sure that you
get the correct installation files. This saves time for the installation process and
saves space on the Tivoli Provisioning Manager for OS Deployment Server.

Follow these steps to integrate the Service Pack 2 into the Windows XP
Professional image on the hard drive:

1. Download the full “Network Install” of the service pack and save it to a
directory on your hard drive (in our example X:\winXPimg\SP2)

Note: Do not use spaces in the folder name.

20 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

2. Locate your local copy of the Windows XP source files that were created in

2.2.1, “Copying the media files” on page 19.

3. Open a command prompt (start → run → cmd) and go to the folder where
you copied Service Pack 2. Type the command as shown in Example 2-2

Example 2-2 Unpacking and integrating Service Pack 2 into Windows XP

x:\winXPimg\SP2\WindowsXP-KB835935-SP2-ENU /integrate:X:\winXpimg\i386

After issuing the command above you should see the files being extracted and
then integrated into the Windows XP files as shown in Figure 2-2

Figure 2-2 Service Pack 2 unpack and integration in progress

After the extraction and integration is completed you should get a confirmation
that Windows XP Service Pack2 has now been slipstreamed into your original
Windows XP files as shown in Figure 2-3

Figure 2-3 SP 2 integrated successfully

At this point the Service Pack 2 is integrated into the base code. This process is
pretty much the same for all Windows operating system variants.

Chapter 2. First-time installations 21

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

2.2.3 Creating the unattended profile

The main purpose of creating an unattended profile is to allow for a native
installation of Windows XP to occur without replicating a pre-existing reference
system. In our scenario, we assume there is no existing reference system to
utilize. Therefore, we are building the system through the unattended profile
process which will become the reference system for future installations which we
can utilize for mass distribution.

We perform the following steps to create an unattended profile for Windows XP:

1. Log in to the console, select OS Deployment → Profiles → Folders →
System Profiles → Add a new profile, as shown in Figure 2-4.

Figure 2-4 Launching the Profile Wizard

2. In the first profile wizard window, choose the Unattended setup (scripted
install), as shown in Figure 2-5 on page 23. This is because we want to

install a new operating system using the installation CDs. Since one of the
main purposes of Tivoli Provisioning Manager for OS Deployment is to make
the installation process simpler and faster, the profile wizard will continue
prompting the installation parameters in order to avoid the manual
intervention on the client machine after the deploy now command is
submitted. All the parameters that are needed to install an operation system
on a bare metal machine are automatically validated to the process without
any user intervention at a later time. Moreover, Tivoli Provisioning Manager

22 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

for OS Deployment allows users to modify these configuration parameters
after the completion of the wizard. This is shown in the RedBook Deployment
Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1,
SG24-7397 in section 4.3.1.

Figure 2-5 Selecting unattended installation

3. In the next profile wizard window it asks you the operating system that will be
contained in the profile. In this case select “A Windows 2000/2003/XP
system profile” option as shown in Figure 2-6

Figure 2-6 Creating a Window XP profile

Chapter 2. First-time installations 23

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

4. In order to select a location for the operating source files, it is required to
either install the Web Interface extension, select a system that has the Web
Interface extension, or import from the local import directory. This process is
shown in Figure 2-7 on page 24.

Figure 2-7 Connecting to the Web Extension

5. The next step is to specify where the installation files are located. Tivoli
Provisioning Manager for OS Deployment will copy the installation files into its
own system. This way they will be protected from outside changes, plus Tivoli
Provisioning Manager for OS Deployment can optimize disk usage by keeping
files only once across all images. Since we have the files on a local hard
drive, we will click on the browse button, as shown in Figure 2-8.

24 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-8 Browse to source location

6. In our scenario we select the location where the files are located on the Tivoli
Provisioning Manager for OS Deployment server as shown in Figure 2-9 on
page 25.

Figure 2-9 Source File Location Specified

7. Next Tivoli Provisioning Manager validates the location that you specify as the
source location and detects what installation software is available. In our
scenario the profile wizard detects the correct Windows XP operating system
and we select the Next button to move on to the next window in the profile
wizard as shown in Figure 2-10.

Chapter 2. First-time installations 25

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-10 Operating system source files detected

8. Next we are prompted to define the partition size that will be used for the
Windows XP installation. This can be defined as an absolute value or as a
proportion of the available space. As you are unlikely to know the size of all
target disks, we recommend that you specify to use 100% of the disk as
shown in Figure 2-11 on page 26.

Tip: If you prefer to keep certain files on a system even after a
redeployment of the operating system, create a second partition and place
those files there.

Figure 2-11 Disk partition sizing question

9. Next we specify NTFS as the filesystem type and to use the entire disk as
shown in Figure 2-12

26 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-12 Specify filesystem type and size in percentage format

10.Next we confirm that we have defined one NTFS partition using 100% of the
disk as shown in Figure 2-13 on page 27.

Figure 2-13 Confirm fileystem size and format

11.In order for Tivoli Provisioning Manager for OS Deployment to install
unattended we must specify the product key for the unattended installation as
shown in Figure 2-14.

Chapter 2. First-time installations 27

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-14 Input product key

12.Next we specify additional fixed properties to use for all machines that you
deploy this system profile on. If left blank, these properties have to be set
indivitdually for each host or Windows setup might ask for them interactively.
In this case we set the fixed properties as shown in Figure 2-15 on page 28.

Figure 2-15 setting fixed properties

28 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

13.Next we specify a custom unattended.txt for advanced settings that you want
to use in your system profile. We leave this blank in our unattended
installation as shown in Figure 2-16.

For information about the unattended.txt file consult the help file ref.chm
which is included in the Windows XP Deployment tools. A link is provided in ,
“Online resources” on page 142.

Figure 2-16 Specifying unattend.txt file or advanced settings

14.Next enter a descriptive name and relevant comments as shown in
Figure 2-17 on page 30. Note that only the name will be shown when
chossing the profile during deployments, so make sure it is descriptive.

Chapter 2. First-time installations 29

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-17 Entering name and comments for the profile

15.Finally, we confirm the creation of the profile and finish the profile creation as
shown in Figure 2-18.

30 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-18 Finishing the unattended profile creation wizard

The above steps has now resulted in a profile for an unattended installation of
Windows XP professional with Service Pack 2 integrated.

2.3 Adding drivers

In the point-of-sale environment the chances of having different types of
hardware to deploy to is very high. In our case we had four different types of
SurePOS systems, each requiring a different set of drivers. We found that it was
critical to inject the proper system board drivers at a minimum during the
installation process in order for the system to be usable after installation. This
section will go through the process of importing a driver into the TPM for OS
Deployment file repository and associating it with the proper type of device.

Note: This procedure works only for PnP drivers. If you want to make an
image with additional Mass-storage drivers then there is a Technote
documenting the procedure. To find the Technote, search the Tivoli support
site for incident 1260552.

Chapter 2. First-time installations 31

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

2.3.1 Downloading and unpacking the drivers

Drivers are prepared in Tivoli Provisioning Manager for OS Deployment as
software packages. The following steps show how a system board driver for a
SurePOS system is downloaded, unpacked and created as a device driver
software package that can be used during deployments.

1. First, download the appropriate driver file from the relevant web site. The
latest device drivers for IBM SurePOS systems can be found at

http://www2.clearlake.ibm.com/store/support. In our case we are creating

a driver package for the system board driver for the IBM SurePOS System
type 4840-553. which are in the file intelinf-2kxp04101012.exe as shown in
Figure 2-19.

Figure 2-19 System board driver package

2. Next, we run the executable for system board driver and select an extract
location for the files and click the Unzip button as shown in Figure 2-20 on
page 32.

Figure 2-20 Select Extract location for driver package

3. After the extract of the system driver completes sucessfully click the OK
button to confirm the completion of the extract as shown in Figure 2-21.

32 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-21 Drivers unpacked

4. Next go to a command prompt and extract the *.inf files for the system board
drivers by running the command as shown in Example 2-3. The actual
unpacking varies from one driver to the other so always consult the
documentation or readme textfile.

Example 2-3 Extracting the drivers

c:\drivers\inf>setup -A -A -P c:\tmp\driverExtract

5. The setup utility is launched as shown in Figure 2-22 on page 33.

Figure 2-22 Driver setup wizard is launched

6. Next Accept the license agreement as shown in Figure 2-23.

Chapter 2. First-time installations 33

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-23 Accepting the license agreement

7. The Readme Information will be displayed. Click the Next button as shown in
Figure 2-24 on page 35.

34 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-24 Review Readme Information

8. Verify that the files were extracted to the destination location as shown in
Figure 2-25.

Chapter 2. First-time installations 35

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-25 Display the extracted inf files

2.3.2 Creating a software package for device drivers

Once the inf files for the driver are exposed through a process as shown in 2.3.1,
“Downloading and unpacking the drivers” on page 32, the drivers can be
packaged in Tivoli Provisioning Manager for OS Deployment. In order to package
the driver follow the steps listed below:

1. Login to the Tivoli Provisioning Manager for OS Deployment console and go
to OS Deployment → Software Packages, and click the “Add a New

Software package” button on the bottom left as shown in Figure 2-26.

36 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-26 Create a new driver software package

2. Next, select the “Windows 2000/2003/XP” option and click Next as shown in
Figure 2-27.

Chapter 2. First-time installations 37

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-27 Select a software package for the Windows Platform

3. Next, select “A Windows driver to include in a deployment” and click Next as
shown in Figure 2-28.

Figure 2-28 Select a driver software package to create

38 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

4. Next, select to look in the server’s import directory for the driver location as
shown in Figure 2-29 on page 39.

Figure 2-29 Select the local server import directory to get the driver files

5. Browse the import directory and select the driver directory location as shown
in Figure 2-30.

Figure 2-30 Select the directory where the driver files are located

Note: Point to the directory that contains the *.INF files. Most driver
packages expand to several subdirectories.

Chapter 2. First-time installations 39

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

6. After selecting the directory, click Next and you should see the following.
Notice that there is a checkbox for “Automatically bind this driver to hosts,
using PCI device identifiers.” as shown in Figure 2-31 on page 40. Select this
checkmark.

Figure 2-31

7. Click Next, and you are presented with another chance to add your own
comments to the driver package as shown in Figure 2-32.

Figure 2-32 Naming of the software package and adding comments

40 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

8. Click Next, and you will be presented with where Tivoli Provisioning Manager
for OS Deployment is storing the files and also at what stage the driver will be
injected as shown in Figure 2-33 on page 41.

Figure 2-33 Driver upload details

9. Click Next and the import will begin as shown in Figure 2-34.

Figure 2-34 Driver import progress

Chapter 2. First-time installations 41

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

10.Once the upload of the driver is completed, Click the Finish button as shown
in Figure 2-35 on page 42.

Figure 2-35 Finishing the software package wizard

You will now have the system board driver listed in the Software Packages
section of the Tivoli Provisioning Manager for OS Deployment console as shown
in Figure 2-36.

Figure 2-36 Driver package sucessfully created

42 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

2.4 Deploying to a pristine system

After creating the unattended profile as shown in 2.2.3, “Creating the unattended
profile” on page 22, we create a deployment scheme and deploy the profile to a
target IBM SurePOS client machine. In this section we cover:

򐂰 The creation of a deployment scheme
򐂰 How to modify an unattended profile for a dynamic host name
򐂰 The process the client machine goes through during boot and installation

2.4.1 Creating a deployment scheme

Before deploying a profile on a target computer, you must specify how your
profile is going to be deployed. In Tivoli Provisioning Manager for OS
Deployment, this is done through Task Templates → Deployment Schemes. In
order to create a deployment scheme follow the step by step instructions below:

1. First, login to the Tivoli Provisioning Manager for OS Deployment console and
select OS Deployment → Task Templates → Deployment schemes. Right-
mouse-click on Deployment Schemes and select New Deployment
Scheme as shown in Figure 2-37.

Figure 2-37 Creating a new deployment scheme

Chapter 2. First-time installations 43

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

2. Select a name for the deployment scheme as shown in Figure 2-38 on
page 44.

Figure 2-38 Adding a descriptive name for the deployment scheme

3. When the deployment starts, host-specific parameters can be modified
interactively during deployment or taken from the unattended install. In
addition, there are other deployment options that can be set. In this case we
leave the default settings as shown in Figure 2-39.

44 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-39 Defining host-specific parameters during deployments

4. Next, set the configuration for the data collection policy as shown in
Figure 2-40 on page 45. In this scenario, we leave the default configuration
and click Next.

Figure 2-40 Data collection policy

Chapter 2. First-time installations 45

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

5. Next, we select what to do after the deployment is completed. In our scenario
we want the terminal to boot from the newly completed deployment; therefore,
we select the second option as shown in Figure 2-41.

Figure 2-41 Selecting action after completed deployment

6. Next, we configure the network usage during deployment by selecting
between unicast, multicast with synchronization, and multicast without
synchronization. In this scenario we take the default of unicast as shown in
Figure 2-42 on page 46 which will allow the system to not share bandwidth
during the installation. Please refer to section 6.3, “Network Bandwidth
Considerations” on page 132 for details on the different network options.

Figure 2-42 Selecting network usage

7. Next, we select the on-site redeployment features for the deployment scheme.
In this scenario we take the default as shown in Figure 2-43. Redeployments
are discussed in Chapter 4, “Redeployment scenarios” on page 83.

46 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-43 Optional selection of redeployment feature

8. Finally, select the finish button as shown in Figure 2-44 on page 47 to
complete the creation of the deployment scheme.

Figure 2-44 Finish the deployment scheme wizard

Chapter 2. First-time installations 47

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

2.4.2 Modifying the unattended profile for a dynamic host name

Some organizations have very strict computer naming conventions while others
are happy for a host to be assigned a number from a random pool. There is a lot
to be said about the pros and cons of each naming style. However, some form of
a naming standard is required in order to keep track of the different systems in
the environment. This is especially true in a large retail environment with multiple
locations and different types of machines. If a naming standard is not maintained
it may become difficult to locate a particular machine that needs repair or
determine what function the device provides. This problem only gets more
complicated in a retail environment with a central IT department that manages
several remote warehouses and stores each with many devices in each location.
Tivoli Provisioning Manager for OS Deployment offers a number of ways to
register a hostname within the system:

򐂰 Manually type a name into the Web console after a computer registers with

Tivoli Provisioning Manager for OS Deployment, but has not yet had an image
deployed. This is fine for one or two computers but during a major deployment
it can become very laborious.

򐂰 Import a list of hostnames. This is a good way to populate the host database,

especially if the computer naming convention does not rely on any
characteristic of the actual computer. Each name however must be linked
some way to a unique characteristic of a computer. This could be the MAC
address, the UUID/GUID, the serial number, or a fixed asset tag. These could
be acquired from the manufacturer with the hardware shipment. In short,
Tivoli Provisioning Manager for OS Deployment must have some way of
uniquely identifying a computer to allow the match up with a pre populated
host name. The import host button is at the bottom of the Host monitor
panel.

򐂰 Automatically generate a host name. Tivoli Provisioning Manager for OS

Deployment has a variety of keywords that will allow the extraction of all or
part of a key hardware identifier and build it into the hostname according to a
template. This means you could incorporate all or part of the computer’s serial
number or asset number into its hostname.

򐂰 Let Tivoli Provisioning Manager for OS Deployment decide. Tivoli

Provisioning Manager for OS Deployment will assign a random hostname.

In our scenario, we used the ability for Tivoli Provisioning Manager for OS
Deployment to automatically generate a host name with the use of keyword
variables. In order to achieve this the values in the Fixed Hosts properties can
contain special keywords or variables that are replaced by dynamic information.
This can be helpful when trying to dynamically create hostnames for systems.
Below are the supported keywords:

48 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Table 2-1 Fixed host properites keywords

Variable Description Syntax

IP Full IP address received by

DHCP

MAC hardware address [MAC]

SN serial number as found in

DMI (SMBIOS)

BOMID unique host identifier in the

Tivoli Provisioning
Manager for OS
Deployment server
database

AT DMI asset tag [AT]

GRP deepest administrative

group name to which the
host belongs

DHCPNAME host name as known to the

DHCP server

[IP]

[SN]

[BOMID]

[GRP]

[DHCPNAME]

Every keyword supports a range extension if you want to include only part of the
dynamic information. The range starts at value 0. [IP3] corresponds to the last
byte of the IP address. [IP1-3] corresponds to bytes 1 to 3. [MAC3-5] is replaced
by the last three bytes of the MAC address. For AT, GRP, DHCPNAME, the range
corresponds to a substring. In our example, we will be using the last three bytes
of the MAC address. Below are the step by step instructions to modify the profile
to add a dynamic hostname:

1. First, login to the Tivoli Provisioning Manager for OS Deployment console and
select OS Deployment → Profiles and select the profile that needs the
dynamic hostname. Select the configure button located at the bottom of the
screen as shown in Figure 2-45 on page 50.

Chapter 2. First-time installations 49

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-45 Select profile for editing

2. Next, select the edit button on the Fixed Host Properties screen as shown in
Figure 2-46. This will allow manual editing of the parameters.

Figure 2-46 Select fixed host properties for editing

3. Finally, add the variable into the “Hostname to set” field as shown in
Figure 2-47 on page 51.

50 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Figure 2-47 Adding a variable into the hostname

2.4.3 Client Machine Boot and Deploy

To start the boot process and deployment of the scheme, login to the Tivoli
Provisioning Manager for OS Deployment console and select OS
Deployment → Host Monitor. Right mouse click on the host that needs the
deployment and select “Deploy Now” as shown in Figure 2-48.

Chapter 2. First-time installations 51

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 2-48 Starting the actual deployment

The Deploy Now feature should trigger that the client machine performs a
network boot in order to load the Tivoli Provisioning Manager for OS Deployment
mini operating system. This is a simple operating system that contacts the Tivoli
Provisioning Manager of OS Deployment server and runs the deploy on the
target machine. Below is the process the client machine runs in order to
accomplish the deploy now function:

1. Power On: A user or a wake-up event starts the client boot sequence.

2. Network Boot: The BIOS configuration (boot order), a hot key (typically the
F12), or wake-up event instructs the computer to boot on the network.

3. IP address discovery: The client machine broadcasts a DHCP request for an
IP address. Any DHCP server which knows the client or which has a pool of
freely distrubutable dynamic addresses sends an IP address. The client takes
the first answer and confirms it to the server. In addition to the IP Address, the
DHCP server gives some other network parameters to the client, as well as
information on the boot procedure.

4. Boot server discovery: The client computer then proceeds to the discovery of
the boot server. The boot server is responsible for delivering a network boot
program to the client. It is not necessarily the same computer as the DHCP
server. The client responds to the first boot server which replies and
downloads a small program using a simple multicast protocol (MTFTP).

5. Server connection: If the network boot program is the deployment engine, it
establishes a secure (encrypted) connection to the Tivoli Provisioning

52 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch02.fm

Manager for OS Deployment server and receives instructuions form the
server to determine the name of the program to execute.

6. The client determines that it is starting a new deployment and queries the
server for relevant deployment configuration. The client performs hardware
discovery through DMI and PCI system calls. If specified in the configuration,
it prompts the user for additional deployment information. The client then
queries the ODBC/JDBC™ database for all relevant information regarding the
operating system and the software packages to be installed and dynamically
generates a deployment script.

7. The client partitions its hard disk according to the information retreived from
the database. A small bootstrap is also written to the hard disk, so as to be
able to take over any subsequent reboot on the hard disk. This is called the
fake MBR.

8. The client initiates a batch multicast transfer for all files needed during the
deployment. The files are downloaded in the order which optimizes the
efficiency of the multicast download. A virtual image of the wanted hard-disk
state is built by merging the base operating system image and all incremental
images and other software updates. The data is then written onto the disk.

9. An answer file is dynamically generated, providing all necessary information
for an unattended configuration of the operating system image. The client
computer boots in the mini-setip, and completes operating system installation
and executes unatteded setup command lines for the selected software
packages. The client reboots and Tivoli Provisioning Manager for OS
Deployment takes control again. If the computer is still connected to the
network, it automatically uipdates the deployment status in the database.

10.When everything is done, the deployment process terminates by either
turning off the computer, starting up into the operating system, restarting the
computer, or displaying a green banner.

Chapter 2. First-time installations 53

4372ch02.fm Draft Document for Review November 15, 2007 3:27 pm

54 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

3

Chapter 3. Mass-Distributions

In this chapter we cover the typical mass distribution scenarios. We take a base
point-of-sale system that we deployed with the unattended profile in previous
chapter, and go through the steps for creating a cloning profile based on that
unattended installation for mass distribution to a greater population of
point-of-sale devices. The topics we cover include.

򐂰 Preparing a system for being captured
򐂰 Capturing the image and creating the cloning profile
򐂰 Adding additional drivers and creating rules for different hardware types
򐂰 Deploying the cloning profiles

© Copyright IBM Corp. 2008. All rights reserved. 55

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

3.1 Creating a cloned profile for Windows XP

Tivoli Provisioning Manager for OS Deployment’s native mode of operation is
centered around cloning system profiles. Deployment through the cloning
method is faster than an unattended installation. In this section we will explore
the details and the steps required to clone a system.

3.1.1 Preparing the donor system

Tivoli Provisioning Manager for OS Deployment does not perform any clean up
on your machine. Before we can clone a Windows XP machine, we must
therefore make sure that the system is as clean as possible. This includes the
following cleanup activities:

򐂰 Empty the system recycle bin
򐂰 Delete the internet cached files - cookies and history
򐂰 Delete temporary directories and files
򐂰 Disconnect any network shares and remote printers

After the cleanup process has been completed perform the following activities:

1. Login to the system that is to be cloned.

2. Before we can create a windows profile we have to run a Microsoft utility
called sysprep on the system that will be our master image for future cloning.

Sysprep places the operating system in a condition that is as though it was
just installed on the systerm and before the inital windows setup occurs.
Sysprep is available from Microsoft’s web site. A link is provided in the section
“Other publications” on page 141. The sysprep file we used for this project
was WindowsXP-KB838080-SP2-DeployTools-ENU.cab. Extract the cab file
to c:\sysprep as shown in Figure 3-1 on page 57.

56 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-1 Sysprep files extracted

3. Next, run C:\sysprep\sysprep.exe and click ok on the warning message as
shown in Figure 3-2.

Figure 3-2 Warning message for security modification

4. Select “mini-setup”. Ensure that the Shutdown Mode is set to “Shutdown”,
then click reseal as shown in Figure 3-3 on page 58.

Chapter 3. Mass-Distributions 57

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-3 Options for the System Preparation Tool

5. Click ok on the warning dialog that appears and then after a short delay the
machine will be shutdown and we are ready to capture the image as shown in
Figure 3-4

Figure 3-4 Warning for sysprep

The system is now ready for system capture.

58 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

3.1.2 Capturing the system image

1. Power on the Window XP System that is to be cloned and boot it to the
network so that Tivoli Provisioning Manager for OS Deployment can discover
and manage it as shown in Figure 3-5 on page 59. After the TPM server
identifies the computer and writes a basic hardware scan data into the Tivoli
Provisioning Manager for OS Deployment database, the guest will display the
following screen. If you do not see this screen within a 30 seconds of the
splash screen then you may have some server communication issues.

Tip: Forcing the IBM SurePOS system to boot from the network may
require changes to the boot order. This is described in Appendix A,
“Alternate boot sequence on POS systems” on page 133

Figure 3-5 Booting the system to be cloned

2. Login to the server Console and select the OS Deployment → Host Monitor
in the left panel. Select the newly discovered system in the Host Monitor’s
host view and choose Start admin toolkit from the left panel menu. Or,
right-click on the discovered host and select Start admin toolkit from the
pop-up menu as shown in Figure 3-6 on page 60.

Chapter 3. Mass-Distributions 59

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-6 Starting the admin tookit

3. Next, take the default setting and click the OK button on the Start Admin
toolkit options screen as shown in Figure 3-7.

60 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-7 Admin Tookit Options

4. Go to client SurePOS system that is being cloned and the admin toolkit
should be loaded. Select “Make a new image” as shown in Figure 3-8 on
page 62.

Chapter 3. Mass-Distributions 61

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-8 Select make new image from the admin toolkit

5. Next, select “Create a System Profile” as shown in Figure 3-9 on page 63.

62 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-9 Selecting create a system profile

6. Click in the Description field and press the ESC key. That will clear out the
text. Then type something like, “Retail SurePOS Master Image” as shown in
Figure 3-10 on page 64.

Chapter 3. Mass-Distributions 63

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-10 specify a name for the image to be captured

7. In the next panel, Tivoli Provisioning Manager for OS Deployment has actually
scanned the system itself and detected the specific version of the Operating
System installed as shown in Figure 3-11 on page 65.

64 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-11 Verify the Operating system for capture

8. In the next panel enter the model number to ensure that the profile is
deployed only to the proper model. In this scenario the image is being
captured for use across all of our different IBM SurePOS system models;
therefore, we use the generic IBM SurePOS as the model as shown in
Figure 3-12 on page 66.

Chapter 3. Mass-Distributions 65

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-12 Specify the model for the image

9. Finally, click the Next button and the image will begin to be captured. The
image build will take several minutes. This time will vary greatly depending on
the size of the image, and the network between client and server, as shown in
Figure 3-13 on page 67.

66 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-13 Capturing the OS image

10.After the capture has completed successfully click ok to confirm the
successful completion of the image capture as shown in Figure 3-14 on
page 68.

Chapter 3. Mass-Distributions 67

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-14 completed image capture

We now have an image on the Tivoli Provisioning Manager for OS Deployment
server, that we can use for deployment to multiple systems. Before we do this,
however, it is recommended to do some adjustments, including adding device
drivers and define hostnaming standards.

3.1.3 Configuring the system profile

A significant characteristic about Tivoli Provisioning Manager for OS Deployment
is that we have not simply copied the disk sectors to create the clone image.
Instead, we copied the files from the donor machine. This means that we can
now browse and change the details of the profile after it is captured. From here
you can do the following:

򐂰 Add and delete files and directories from the image
򐂰 Change the hard disk layout
򐂰 Review the binding details for computer models
򐂰 Change and view the system code page
򐂰 Add additional user binding categories

68 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

If we edit the profile details, we can add system category information, which then
allows us to associate this profile with specific software packages. After we finish
with the profile details, we can modify the details of the disk partitions in the
image. In the profile configuration summary we see that we can make custom
additions to the sysprep.inf file. Remember that this file is used when the image
is deployed to a new target. Such modifications are useful to allow us to run
custom actions when the deployment is completed. They might include the
following:

򐂰 A script to update an associated Change Record
򐂰 A script to send an e-mail notification to an Administrator

The sysprep process is documented at the following web site:

http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/duplicatio
n.mspx

Details of the contents of the sysprep.inf file are documented at the following
Web site:

http://technet2.microsoft.com/WindowsVista/en/library/71b576bd-cca6-466
f-a1db-16500be3098f1033.mspx?mfr=true

If you want to do something simple like run a script after installation completes,
then see Example 3-1, which gives you the critical but incomplete items from the
sysprep.inf file that you will need. In this example, we run the
c:\run_this_command.cmd file the first time that the target machine boots after
installation.

Example 3-1 running a script after deployment is completed

[Unattended]
[GuiUnattended]
AutoLogonCount=1
AutoLogon=Yes
[GuiRunOnce]
Command0=C:\run_this_command.cmd

3.2 Adding support for different hardware types

The cloning profile that we created in the previous section is currently perfect for
exactly one type of hardware, namely the one we used to create the master
image.

Chapter 3. Mass-Distributions 69

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

With Tivoli Provisioning Manager for OS Deployment it is possible to use the
same cloning profile for different types of hardware. During deployment, Tivoli
Provisioning Manager for OS Deployment identifies the hardware and based on
binding rules, the correct drivers are injected at the appropriate stage of the OS
installation.

In this scenario we go through the steps for creating additional drivers, specify
binding rules and installation sequences, so the cloning image can be used for
different types of hardware requiring different drivers.

The steps for adding support for a new hardware type using an existing cloning
profile are:

򐂰 Download the appropriate devce drivers for the new type of hardware
򐂰 Create device driver software packages for each new type of hardware
򐂰 Validate the correct binding rules exist for the new hardware

The process for adding support for new hardware types is illustrated in
Figure 3-15.

Figure 3-15 Process for adding support for new hardware types

The creation of device drivers is described in 2.3, “Adding drivers” on page 31
and will not be described further in this chapter.

70 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

3.2.1 The principle of device driver injection

In the point-of-sales environment the chances of having different types of
hardware to deploy to is very high. In our case we had four different types of
SurePOS systems each setup needed a different set of drivers. This section will
go over the principle of device driver injection.

If a required device driver is not contained within the profile that is being
deployed to a new target, then at best the hardware on the target will not be
exploited, for example resulting in poor screen performance. At worst, the
network cards will not initialize correctly, and the system will not have network
access to correct the problem.

Instead of having the cloned machine image contain all the possible device
drivers, Tivoli Provisioning Manager for OS Deployment adopts a different
approach and allows to inject the required drivers into the image at deployment
time. This means that you can always use the same image, and Tivoli
Provisioning Manager for OS Deployment dynamically binds the hardware
specific device driver to the deployment for your particular hardware. This
process is accomplished through the uniquely set identifiers that exist on all PCI
based devices.

This principle is described in full details in the IBM RedBook Deployment Guide
Series: Tivoli Provisioning Manager for OS Deployment V5.1, SG24-7397.

3.2.2 Software Bindings

When a device driver software package is created, the binding rules are created
automatically at the time of package creation as shown in Figure 3-16.
Configuration and software bindings that are not the result of an automatic
binding rule can be modified using the binding interface in the Host Monitor.
Automatic binding rules are used to create bindings between configuration and
hosts, or between software packages and hosts, without having to specifically
bind a configuration or a software package to each host. Rules are created in
configurations and software packages to determine which hosts will
automatically be bound to the configuration or software package.

Chapter 3. Mass-Distributions 71

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-16 Device driver software package binding rules

Rules are made for criteria and values. If a host has a matching value for all
criteria in the rule, the configuration or software package will be bound to the
host. The binding will be displayed with the rule in the configuration panel of the
host properities that match the criteria.

3.2.3 Deployment Scheme Parameter Wizard

Deployment schemes allow an administrator to create different deployment
methods. For example, you can ensure that the deployment user must specify
the hostname for each deployment. Deployment schemes are explained in
section 2.4.1, “Creating a deployment scheme” on page 43.

3.3 Deploying the XP cloning profile

The deployment is the process of installing an operating system on a computer,
and configuring the operating system on a given set of hardware, which in our
case is IBM SurePOS system. In Tivoli Provisioning Manager for OS
Deployment, a deployment is made of several steps that are executed in
sequence without requiring user interaction.

1. Partitions are created on the hard-disk, and then formatted according to
information contained in the system profile to deploy.

2. All deployment objects (system profile, partition files and software packages)
are downloaded in a temporary storage location on the hard-disk.

72 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

3. Operating system files are written in the hard-disk partitions, thus creating a
bootable operating system with files and applications configured by database
bindings between the host and software packages.

4. Host-specific configuration, like the hostname and the product key are
gathered from the database to create a textual configuration file used by
Microsoft’s System Preparation Tool (sysprep) for Windows deployment.

5. The operating system is started, allowing sysprep to configure the operating
system according to information stored in the Tivoli Provisioning Manager for
OS Deployment database.

6. Tivoli Provisioning Manager for OS Deployment takes control again when
sysprep has completed and rebooted the computer, in order to display a
message indicating that the deployment was successful.

Deployment step by step

Now that we have captured an image, added applications, and added drivers, we
are ready to deploy the Windows XP Image to a system that will be put into
production after deployment:

1. Power on the SurePOS target machine. Assuming there is no operating
system on the system (the hard drive is blank), you can simply let it boot up
and it will try to boot the network as part of the regular boot sequence. If there
is an operating system, force the system to boot from the network, as
described in Appendix A, “Alternate boot sequence on POS systems” on
page 133. Once the network boot has completed you should see a screen as
shown in Figure 3-17 on page 74.

Chapter 3. Mass-Distributions 73

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-17 A system booted from network and connected to TPMfOSD

2. After the client completes the network boot, return to the server console and
select Host Monitor from the left margin to ensure that the system is
discovered. Right-click on the newly discovered system and select Deploy

now as shown in Figure 3-18 on page 75.

74 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-18 Selcting deploy now from the server console

3. The deployment wizard will be displayed as shown in Figure 3-19. Click Next.

Chapter 3. Mass-Distributions 75

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-19 The deployment wizard

4. Next, keep the default option of Simple Deployment and click Next as shown
in Figure 3-20 on page 77.

76 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-20 Selecting a simple deployment

5. Select the deployment scheme that was created earlier similar to the
deployment scheme created for the unattended installation, but in this case
for the clone. In this scenario the deployment scheme is called “Unattended
clone profile”. We select the deployment scheme and click Next as shown in
Figure 3-21.

Chapter 3. Mass-Distributions 77

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-21 Selecting the deployment scheme for cloning

6. Select the WinXP Image that we created in the previous section and click

Next as shown in Figure 3-22 on page 79.

78 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-22 Selecting the Windows XP configuration

7. Accept the remaining defaults and click Finish to Start the deployment as
shown in Figure 3-23.

Chapter 3. Mass-Distributions 79

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-23 Finishing the deployment wizard

8. The deployment process will now begin on the target SurePOS machine. You
should see an image in the target SurePOS system as shown in Figure 3-24
on page 81.

80 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch03.fm

Figure 3-24 deployment progress on the target during deployment

9. The system will execute several reboot cycles and you may notice that
fundamental setup information will be automatically entered by the build
process handled by Tivoli Provisioning Manager for OS Deployment. When
the deployment is completed you should see a green banner on the target
system indicating the deployment was successful as shown in Figure 3-25 on
page 82.

Chapter 3. Mass-Distributions 81

4372ch03.fm Draft Document for Review November 15, 2007 3:27 pm

Figure 3-25 Green banner on the target after successful deployment

With the above steps in this chapter, we have shown how to prepare and capture
a cloning image from a master system, configure the profile, add additional
drivers and finally deploy to a new target system.

82 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch04.fm

4

Chapter 4. Redeployment scenarios

Redeployment is the process of quickly reinstalling a system configuration
previously installed by Tivoli Provisioning Manager for OS Deployment to its
initial deployment state. There are two types of redeployments available. A server
based imaging of the corrupted device by the same deployment scheme that was
originally used to deploy the device or the use of a Tivoli Provisioning Manager
for OS Deployment specific feature that is located on a local hidden partition of
the device for recovery. This second redeployment feature of using a hidden
partition to redeploy is especially useful for the retail environment since
point-of-sale devices are used in a variety of locations that might not be easily
accessible by central IT networks. This option gives local users or power users
the ability to repair a corrupted device without the intervention of a central IT
resources and brings business value by limiting the amount of downtime of the
corrupt device. In this section we cover:

򐂰 The reasons for implementing the local redeployment feature
򐂰 Implementation and customization of local redeployment to a point-of-sale

device

򐂰 Server based redeployment

© Copyright IBM Corp. 2008. All rights reserved. 83

4372ch04.fm Draft Document for Review November 15, 2007 3:27 pm

4.1 Reasons for redeployment

We use the term redeployment for the situations where an existing POS system,
that has already been deployed, in operation, and needs to be recovered to its
original state as it was originally installed as a new system.

There are different reasons for redeployments, depending on the environment
and the situation.

򐂰 After a hard drive failure

This is probably the most obvious reason. If the hard drive fails it needs to be
replaced with a new drive which then needs to be provided with operating
system and software from the ground. Since the system itself is already
known to Tivoli Provisioning Manager for OS Deployment, the redeployment
process is very simple.

򐂰 After a software failure

This scenario is a little less obvious. Normally the IT helpdesk will try to figure
out what the actual problem is and try to resolve it. However, almost any
software problem will take more than 15 minutes to resolve, which is enough
to justify issuing a redeployment, which will effectively take around 20-25
minutes, assuming a local server. The redeployment process can be speeded
further up by keeping a redeployment image locally on the system’s hard drive
in a hidden partition.

򐂰 Performance and stability

It is common experience that a computer always works the best and the
fastest on the day it is installed. At that time, the system is completely clean,
free of any undesirable CPU-consuming gadgets, and all programs are
configured for their optimal use by the system administrator. If the systems
are subject to many changes from different end users, but ideally the system
should be clean for the next user, it may be advisable to configure the system
to automatically redeploy itself at every system boot.

The first two reasons are very valid in the POS environments and will be covered
in this chapter. While the reasoning behind performance and stability are also
valid, the typical use of a POS system does not include letting users do any
customizations or even using the systems to other things than the POS
application(s). This type of scenario is more relevant for workstations with public
access, for example in libraries, hotel Internet cafés, schools and so forth.

84 Tivoli Provisioning Manager for OS Deployment in a Retail Environment

Draft Document for Review November 15, 2007 3:27 pm 4372ch04.fm

4.2 Redeployment from the local hard drive

The most efficient method for redeploying is to implement the on-site deployment
feature during the initial deployment. Using this feature will create a hidden
partition on the target system with a copy of the deployed system.

Whenever the system is started, a boot menu is shown with a timeout value so if
no selections are made, the system continues the normal boot of the installed
operating system. If a redeployment is required, the normal boot process can be
interrupted via the boot menu, and a redeployment can be issued.

The process for setting up a system with local redeployment enabled is shown in
Figure 4-1 and includes the following steps:

򐂰 Create a deployment scheme that includes the redeployment feature.
򐂰 Run an initial deployment specifying to preload the operating system as

opposed to normal deployment.

򐂰 Create a boot menu that will be used with the local redeployment feature.
򐂰 Run the redeployment using the deployment scheme and the customized

GUI.

Figure 4-1 Process for setting up a system with local redeployment enabled

Chapter 4. Redeployment scenarios 85

4372ch04.fm Draft Document for Review November 15, 2007 3:27 pm

Using the local recovery is very efficient in terms of recovery time. However it
must be noted that it will not help in the event of a hard drive failure, where the
hidden partition will also be lost.

It is recommended that the profile is customized to enable redeployment on
point-of-sale devices that are not connected to the central IT network through
high speed networks or have configurations that are easily damaged by user
error. This minimizes the amount of time required by a power user or field
technican to repair the device and put it back in service. In most cases the user
of the local redeployment feature will be a power user like a warehouse manager
or a field technican tha is sent to repair the terminal.

4.2.1 Create a deployment scheme that supports redeployment

The first step in preparing for redeployment is to create a deployment scheme
that has redeployment enabled. To create a deployment scheme that supports
redeployment follow these steps:

1. To create a new deployment scheme, open the OS Deployment menu in the
left panel and select Task templates. Then click the button New Scheme.
This initiates the deployment scheme wizard. Start by giving the new
deployment scheme a descriptive name, then click next and go through the
panels and define deployment attributes as with any other deployment. When
you reach the page for the On-site deployment features (Figure 4-2), select
the support for quick redeployment.

Figure 4-2 Enabling quick redeployment feature

86 Tivoli Provisioning Manager for OS Deployment in a Retail Environment