Deployment guide series tivoli provisioning manager for os deployment v5.1 sg247397

Front cover

Deployment Guide Series:
Tivoli Provisioning Manager
for OS Deployment V5.1
Insider’s Guide to TPM for OS
Deployment

Learn how to migrate to VISTA
easily

Best practices for large
deployments

Vasfi Gucer
Damir Bacalja
Dominique Bertin
Richard Hine
Scott M Kay
Francesco Latino

ibm.com/redbooks

International Technical Support Organization

Deployment Guide Series: Tivoli Provisioning
Manager for OS Deployment V5.1

May 2007

SG24-7397-00

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

First Edition (May 2007)

This edition applies to IBM Tivoli Provisioning Manager for OS Deployment V5.1.

© Copyright International Business Machines Corporation 2007. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this Redbooks publication . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Part 1. Planning and architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Introduction to image management . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Device configuration life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Why Vista? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 A deployment project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Requirements for a tool to assist the deployment effort . . . . . . . . . . . . . . 11
1.3.1 Time to value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.2 Resource and maintenance efficiency . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.3 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Common OS deployment scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.1 Rollout of new desktop hardware and SOE . . . . . . . . . . . . . . . . . . . 15
1.4.2 Rebuild of a previously deployed user workstation . . . . . . . . . . . . . . 16
1.4.3 Upgrade of hardware and subsequent Vista install. . . . . . . . . . . . . . 17

Chapter 2. Architecture and deployment scenarios . . . . . . . . . . . . . . . . . 19
2.1 Tivoli Provisioning Manager for OS Deployment features. . . . . . . . . . . . . 20
2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Small site architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.3 Enterprise architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Part 2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment
environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.1 Server installation on Windows systems . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.1.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.1.2 Using alternate Relational Database Management Systems . . . . . . 80

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

3.1.3 Installing the Tivoli Provisioning Manager for OS Deployment server85
3.2 Installing the server on Linux systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.2.2 Installing the Relational Database Management System . . . . . . . . . 93
3.2.3 Installing the Tivoli Provisioning Manager for OS Deployment server97
3.2.4 Configuring the Tivoli Provisioning Manager for OS Deployment
environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.2.5 Run the Tivoli Provisioning Manager for OS Deployment environment
107
3.2.6 Upgrade to fixpacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.3 Initial login and installation verification . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.3.1 Connecting using HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.3.2 Installation verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.4 Advanced DHCP options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.5 Web interface extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.5.1 Installing on Windows systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.5.2 Installing on Linux systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.5.3 Running rbagent from command line . . . . . . . . . . . . . . . . . . . . . . . 130

Chapter 4. Installing pre-Vista systems . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.2 User State Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.2.1 Saving the personality of an XP machine . . . . . . . . . . . . . . . . . . . . 139
4.3 Creating a cloned profile of Windows XP . . . . . . . . . . . . . . . . . . . . . . . . 145
4.3.1 Changing the contents of the cloned machine . . . . . . . . . . . . . . . . 155
4.4 Creating an unattended profile for Windows 2000 . . . . . . . . . . . . . . . . . 171
4.4.1 Creating a slipstreamed OS image . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.4.2 Selecting the Windows 2000 source tree . . . . . . . . . . . . . . . . . . . . 176
4.4.3 Building a custom sysprep.inf with setupmgr . . . . . . . . . . . . . . . . . 178
4.5 Real world OS installation scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.5.1 Configuring the Windows firewall . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.5.2 Removing imaged profile operating system features . . . . . . . . . . . 191
4.5.3 Removing unattended profile operating system features . . . . . . . . 192
4.6 Restoring the machine’s user personality settings . . . . . . . . . . . . . . . . . 198

Chapter 5. Installing Vista systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
5.1 Do I upgrade or replace?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
5.2 Creating an unattended Windows Vista profile . . . . . . . . . . . . . . . . . . . . 215
5.2.1 Creating the Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
5.2.2 Creating the WinPE software package . . . . . . . . . . . . . . . . . . . . . . 225
5.3 Creating a cloning Windows Vista profile . . . . . . . . . . . . . . . . . . . . . . . . 230
5.3.1 Preparing the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
5.3.2 Capturing the System Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

iv Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1

5.3.3 Configuring the System profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
5.4 Deploying a Windows profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
5.4.1 Creating a deployment scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
5.4.2 Registering hosts in Tivoli Provisioning Manager for OS Deployment
server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
5.4.3 Creating a new user through a software package. . . . . . . . . . . . . . 255
5.4.4 Deploying a Vista profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Chapter 6. Installing Linux systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
6.1 Introduction and general requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 264
6.2 Creating an unattended setup profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
6.3 Creating software packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
6.3.1 RPM software packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
6.3.2 Copying and unpacking software packages . . . . . . . . . . . . . . . . . . 280
6.3.3 Executing a command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
6.3.4 Software packages binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
6.4 The deployment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
6.5 Cloning a machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
6.5.1 Capturing the image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
6.5.2 Customizing the captured profile. . . . . . . . . . . . . . . . . . . . . . . . . . . 297
6.6 Deploying the cloned profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Chapter 7. Common deployment features . . . . . . . . . . . . . . . . . . . . . . . . 303
7.1 Configuring RAID arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
7.1.1 Building the bootable DOS diskette . . . . . . . . . . . . . . . . . . . . . . . . 305
7.2 Software package rules and bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
7.2.1 Binding software packages to deployment schemes . . . . . . . . . . . 319
7.2.2 Advanced binding scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
7.3 Collecting inventory from the target machines . . . . . . . . . . . . . . . . . . . . 328
7.4 Device driver injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
7.4.1 How does this process work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
7.4.2 Device driver software package rules with a different OS. . . . . . . . 335
7.4.3 Creating a device driver software package . . . . . . . . . . . . . . . . . . . 336
7.4.4 Quickly building device driver software packages. . . . . . . . . . . . . . 341
7.5 Understanding the host boot settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
7.6 User administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
7.6.1 Creating the authentication domain . . . . . . . . . . . . . . . . . . . . . . . . 353
7.6.2 Setting user permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Chapter 8. Integration and collaboration with other Change Management
products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
8.1 Tivoli Configuration Manager V 4.2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
8.1.1 Installing the Operating System Imaging Solution . . . . . . . . . . . . . 362
8.1.2 Importing a profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Contents v

8.1.3 Scratch installation of a new workstation . . . . . . . . . . . . . . . . . . . . 377
8.1.4 Saving user settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
8.2 Tivoli Provisioning Manager V5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
8.3 Tivoli Provisioning Manager Express V4.1 for Software Distribution . . . 400
8.4 IBM Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
8.4.1 Product components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
8.5 Collaboration with other products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Chapter 9. CD/DVD based deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
9.1 Deployment CD/DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
9.1.1 CD/DVD creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
9.1.2 OS deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
9.2 PXE emulation CD/DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
9.2.1 CD/DVD creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
9.2.2 OS deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Chapter 10. Redeployment and self-healing feature . . . . . . . . . . . . . . . . 419
10.1 Redeployment basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
10.2 Setting up redeployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
10.3 Redeployment scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

Chapter 11. Troubleshooting, best practices, and common questions . 427
11.1 Troubleshooting basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
11.2 Tivoli Provisioning Manager for OS Deployment considerations . . . . . 428
11.3 Server service/daemon troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . 428
11.3.1 Client troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
11.3.2 Error messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
11.4 Common questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
11.4.1 How do I free some space in the shared repository? . . . . . . . . . . 437
11.4.2 How do I register new hosts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
11.4.3 How do I control generated host names for new machines? . . . . 441
11.4.4 How do I create binding rules? . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
11.5 Questions and answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
11.6 Synchronization with the RbAgent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

Part 3. Planning for an engagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Appendix A. Planning for a client engagement . . . . . . . . . . . . . . . . . . . . 461
Services engagement preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Implementation skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Available resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Solution scope and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Basic solution definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Advanced solution definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

vi Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1

Services engagement overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Executive Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Demonstration system set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Hardware and software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Analyze solution tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Creating a contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Estimating timings and activities of the engagement . . . . . . . . . . . . . . . . . . . 472
Perform environmental analysis and plan tasks . . . . . . . . . . . . . . . . . . . . 473
Plan the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Implement the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Close the engagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Appendix B. Sample Statement of Work for Tivoli Provisioning Manager for
OS Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Building an operating system deployment solution . . . . . . . . . . . . . . . . . . . . 480
Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Solution description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Business partner responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Customer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Staffing estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Completion criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

Contents vii

viii Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1

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. 2007. All rights reserved. ix

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

AIX® MVS™ Tivoli Enterprise™
BladeCenter® NetView® Tivoli Enterprise Console®
Candle® PartnerWorld® Tivoli®
DB2 Universal Database™ Redbooks® VTAM®
DB2® Redbooks (logo) ® xSeries®
IBM® ServerGuide™
IMS™ System x™

The following terms are trademarks of other companies:

Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation
and/or its affiliates.

ITIL is a registered trademark, and a registered community trademark of the Office of Government
Commerce, and is registered in the U.S. Patent and Trademark Office.

Adobe, Acrobat, and Portable Document Format (PDF) are either registered trademarks or trademarks of
Adobe Systems Incorporated in the United States, other countries, or both.

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

Access, Active Directory, Aero, BitLocker, Internet Explorer, Microsoft, MS-DOS, MSN, Windows Media,
Windows NT, Windows Vista, Windows, and the Windows logo are trademarks of Microsoft Corporation in
the United States, other countries, or both.

i386, Intel, Pentium, Xeon, 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.

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

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

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

x Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1

Preface

Tivoli® Provisioning Manager for OS Deployment provisions operating systems
(OS) and applications to computers using the PXE (Pre-boot eXecution
Environment) industry standard for bare-metal installation. A bare-metal
installation eliminates the need for an operating system to be present on a local
disk drive. Tivoli Provisioning Manager for OS Deployment is a turn-key solution
to the most common provisioning issues and provides an easy to use, turn-key
solution for education, small-to-medium businesses (SMB) or larger accounts.

In this easy-to-follow IBM® Redbooks® publication we cover different image
management scenarios with Tivoli Provisioning Manager for OS Deployment,
such as Windows® XP, Windows 2003, Vista, and Linux® deployments. We also
discuss how to design and implement a highly-effective image management
solution for small, medium, and enterprise accounts, taking into consideration
network bandwidth limitations and large OS image sizes.

We also provide some best practices on how to integrate Tivoli Provisioning
Manager for OS Deployment with other change management products,
CD/DVD-based deployment, image redeployment, and troubleshooting.

Finally, we cover Tivoli Provisioning Manager for OS Deployment sales
engagement planning, including a sample statement of work. The primary
audience for this section is Tivoli Provisioning Manager for OS Deployment
Business Partners and pre-sales Systems Engineers.

This book is a major reference for IT Specialists and IT Architects working in the
image management area.

The team that wrote this Redbooks publication
This Redbooks publication 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 working at the ITSO
Austin Center. He worked with IBM Turkey for 10 years and has been with the
ITSO since January 1999. He has more than 12 years of experience in systems
management, networking hardware, and distributed platform software. He
worked on various Tivoli customer projects as a Systems Architect in Turkey and
in the United States. Vasfi is also a Certified Tivoli Consultant.

© Copyright IBM Corp. 2007. All rights reserved. xi

Damir Bacalja is an Advisory IT Specialist from IBM Croatia. He holds a degree
in electrical engineering and is also ITIL® certified. He has worked with Tivoli
products in Framework, Tivoli Configuration Manager, Tivoli Monitoring, Tivoli
Enterprise™ Console, Remote Control, and Tivoli Storage Manager, for almost
eight years. He joined IBM as part of IBM Global Services and took part in many
Tivoli implementations. Since 2002 he is part of the IBM Software group as a
Tivoli Technical Sales Specialist for the SEA region. He has strong skills in
UNIX®, Windows, and shell scripting.

Dominique Bertin holds a technology certificate in electric engineering from the
University of Creteil, near Paris in France. He began as a Honeywell Bull
representative on different mainframe customer sites for seven years, and then
started working as a Software Engineer in the National Software Center in the
Bull company. After 12 years at Bull, he joined a software services company that
was acquired by Candle® corporation five years later. After the IBM acquisition
of Candle, he moved to a Tivoli presales position. He is currently assigned to the
Tivoli Configuration Manager, Tivoli Provisioning Manager for OS Deployment,
and Tivoli Provisioning Manager for Software products within the Tivoli Business
Automation segment.

Richard Hine Richard has a bachelors degree in medical science from the
University of Manchester in the UK, and has worked for IBM since 1981. He
worked with IBM Mainframes for 11 years doing services and support roles with
MVS™, IMS™ and VTAM®, taking assignments to teach automation techniques
and assembler programming. During this time, he also took a job supporting the
IBM first Point of Sale deployment in Europe at Boots of Nottingham in the U.K.
He moved to country technical support in 1991 to support IBM network
management tools on distributed systems, where he taught at the international
education center in La Hulpe and supported field services engagements for the
NetView® automationa family of products—both distributed and mainframe.
During this time Richard also did several international services engagements in
the Middle East, and wrote an ANO based TCP/IP monitoring application that
was used in IBM South Africa. Richard moved to Tivoli in 1996 with IBM
acquisition. He worked in a presales role for the UK on all Framework products,
latterly leading the UK Advanced Technology Team. Certified in 2002, Richard
has been published in the Managed View and two other IBM Redbooks
publications. Currently he works with the Tivoli Performance and Business
automation products in a presales capacity for the UK Financial Services Sector.

Scott M Kay is an Advisory Technical Specialist working for the IBM Software
group in Australia. His speciality is Tivoli Business Automation tools. He has 15
years of experience in the IT field. In that time Scott has held various roles from
operational support, SOE development, to systems management. After joining
IBM in 1999 Scott worked in roles all directly related to the Tivoli suite of products

xii Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1

in Global Services, Tivoli Professional services, and finally in his current presales
role in the Software Group.

Francesco Latino is a Level 2 Customer Support Software Engineer in Tivoli
Configuration Manager and Tivoli Provisioning Manager. He holds a Computer
Science degree from the Department of Computer Science, University of Bari.
His areas of expertise include Tivoli Inventory, Tivoli Software Distribution,
Common Inventory Technology, and Tivoli Provisioning Manager for OS
Deployment products. He has skills in procedural and object-oriented
programming, TCP/IP network protocol, J2EE™ platform, and electronic
commerce.

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

Arzu Gucer
International Technical Support Organization, Austin Center

Dennis R Goetz, Peter Greulich, Dennis Ligay, Mike Orr, Hakan Thyr
IBM USA

David Clerc, Anne Vandeventer Faltin, Jacques Fontignie, Marc Vuilleumier
Stueckelberg, Pierre-Antoine Queloz
IBM Switzerland

Elisabetta Rinaldi
IBM Italy

Mike Gare, Kimberly Mungal
IBM Canada

Sean Safron
IBM USA

KaTrina Love Abram
IBM USA

Become a published author
Join us for a two-to-six week residency program! Help write an IBM Redbooks
publication 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.

Preface xiii

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 the following Web site:
ibm.com/redbooks/residencies.html

Comments welcome
Your comments are important to us!

We want our Redbooks publication to be as helpful as possible. Send us your
comments about this or other Redbooks publication in one of the following ways:
Use the online Contact us review book form found at:
ibm.com/redbooks
Send your comments in an e-mail to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

xiv Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1

Part 1

Part 1 Planning and
architecture
In part 1 we introduce the planning and architectural considerations when
deploying a Tivoli Provisioning Manager for OS Deployment environment. We
cover the actual deployment steps in Part 2.

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

2 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1

1

Chapter 1. Introduction to image
management
In this chapter we discuss the concept of the device configuration life cycle and
how Tivoli Provisioning Manager for OS Deployment can assist in this
management process. This is found in 1.1, “Device configuration life cycle” on
page 4.

We look at business needs—the sort of IT changes that are coming and that
justify an investment in a technology such as Tivoli Provisioning Manager for OS
Deployment. We also look at how this technology reduces costs associated with
deployment and redeployment of operating systems. This is found in 1.2,
“Business requirements” on page 8.

Finally several common deployment scenarios involving Tivoli Provisioning
Manager for OS Deployment are discussed at a high level, showing how cost
savings can be made. This is found in 1.4, “Common OS deployment scenarios”
on page 15.


1.1 Device configuration life cycle
Every facet of IT these days seems to have a life cycle management strategy,
process, or best practice, for example, asset life cycle management, software life
cycle management, user account life cycle management, and storage life cycle
management to name but a few. What they all have in common is that through
collective experience the tasks normally undertaken throughout the life cycle of
the item in question were identified so that they can be managed as individual
tasks and as a whole cycle. It is then possible to measure these tasks, the costs
involved with them, and the time they take and improve them in terms of
efficiency, effectiveness, and cost.

The device configuration life cycle addresses the physical management of
computers from the time they are delivered to the time they leave an
organization. Device configuration life cycle management can go by different
names and have tasks with different terminology, usually dependant upon the
vendor you are talking to; however, in essence the main tasks or activities
involved are shown in Figure 1-1.

Tasks and Activities within the Device Configuration Lifecycle

Bare Metal OS Deployment

Backup and Restore Software distribution
Application and Data

Security Configuration Asset and Inventory Management

Software License
Remote Control and usage
Management

Software Maintenance
and Patch Management

Reporting for Critical Decision Making

Figure 1-1 Tasks and activities within the device configuration life cycle


There are many product suites on the market today that can enable or automate
these tasks and a few that claim to do it all. Most organizations, however, already
have mature tools and processes in place for many of the tasks in the life cycle
and are not about to rip and replace their existing solution unless there is a very
good business case to do so. This is where Tivoli Provisioning Manager for OS
Deployment offers an excellent opportunity. Tivoli Provisioning Manager for OS
Deployment is a stand alone product that offers significant integration capability,
so much so that it has already been integrated with Tivoli Provisioning Manager,
Tivoli Provisioning Manager for Software, and soon to be integrated with IBM
Director.


TIVOLI PROVISIONING MANAGER
BARE METAL OS DEPLOYMENT FOR OS DEPLOYMENT
FULL AUTOMATION

Backup and Restore Software distribution

Security Configuration Asset and Inventory Management

Software License
Management



Figure 1-2 Tivoli Provisioning Manager for Operating Systems role in the configuration
life cycle

The core capability of Tivoli Provisioning Manager for OS Deployment is the
ability to intelligently automate the deployment of operating systems. This
capability extends from the many flavors of Microsoft® Windows, through SUSE
and Red Hat Linux to Sun Solaris™. The deployment of an operating system is
the one item in the configuration life cycle that every single computer will
definitely receive at least once and potentially more often during its working life.
This is shown in context of the device configuration life cycle in Figure 1-2.

Chapter 1. Introduction to image management 5

After installed, the product offers cost savings in the following areas:
Deployment manpower
Using Tivoli Provisioning Manager for OS Deployment during a deployment
should significantly reduce the number of personnel and the level of skill
required to deploy the computer workstations. The deployment role becomes
more of a box-moving role as opposed to a technical role.
The universal system profile
Through the use of a universal system profile, it is possible to have one image
and a collection of driver packages for deployment to a range of hardware.
The savings to be made here are in the following areas:
– Image storage space
Due to the ability Tivoli Provisioning Manager for OS Deployment has to
modify an image and to add drivers through driver injection on the fly
during an image deployment, one image and a collection of driver
packages need storage space as opposed to an image for every hardware
model. This is true for the master server and every distributed copy in the
network.
– Image maintenance
Instead of building a new image every time a new model of hardware or
driver is released, all that is required is the packaging of the driver, the
establishment of the rules for the deployment of that driver and testing of
the deployment and rules.
– Image replication
Minimal images mean less time and resources are used to move those
images around the network to where they are needed.
Ease of redeployment
Once an OS is installed using Tivoli Provisioning Manager for OS
Deployment, redeployment is as simple as a few menu clicks in the Web
console. Many organizations have a system to “automatically” reinstall an
operating system. Those automatic solutions usually involve the help desk
consultant talking the user, or worse, the user’s colleague, through the steps
required to enter all the information needed to kick off a rebuild and then
waiting the hour to hour and a half for the build to complete. In some cases, a
rebuild requires a site visit by a technical staff member.
The savings that can be made here are harder to quantify but easy to identify.
Any time a user is taken away from their core responsibility to help fix a
problem is a business cost. In an organization large enough, it is easy for
these distractions to add up to lost man-days on a daily basis due to users
being involved in helping with a fix.


Tivoli Provisioning Manager for OS Deployment also touches other parts of the
device configuration life cycle with functionality that enables the core OS
deployment functionality, as can be seen in Figure 1-3.


TIVOLI PROVISIONING MANAGER
Bare Metal OS Deployment FOR OS DEPLOYMENT
DEPLOYMENT ENABLING FUNCTIONALITY

Backup and Restore SOFTWARE DISTRIBUTION

Security Configuration ASSET AND INVENTORY
MANAGEMENT

Software License
Management



Figure 1-3 Deployment enabling functionality of Tivoli Provisioning Manager for OS
Deployment

Deployment enabling functionality
Tivoli Provisioning Manager for OS Deployment’s core function is its ability to
deploy operating systems. Included in the product are some other capabilities
that enable this core function. Following are these capabilities:
– Software distribution
The software distribution capability gives Tivoli Provisioning Manager for
OS Deployment the ability to inject driver packages into an operating
system during deployment and install software after the operating system
starts.
– Inventory
When Tivoli Provisioning Manager for OS Deployment boots a computer
using PXE, it automatically scans the computer and stores this data in its


database. Having the results of these scans available allows Tivoli
Provisioning Manager for OS Deployment to make decisions based on this
data about which drivers to inject during OS deployment and which
software to deploy after OS deployment.

Coupled with the enabling capabilities, Tivoli Provisioning Manager for OS
Deployment is able to intelligently install a full SOE in an automated manner
completely automating the first task in the device configuration life cycle, bare
metal OS deployment.

1.2 Business requirements
High-level business requirements are simple: help me save money to improve
my profitability or efficiency. But as you start to drill down into this requirement it
starts to become a little less clear cut. Quite often you have to spend money now
to make a longer term gain or to avoid spending more money later. And so it is
with Microsoft’s Vista. Do I migrate now? The promise is so great, easier support,
greater security, but then there is the cost of doing it now and the potential for
problems. The remainder of this section discusses the reasons an organization
would migrate to Microsoft Vista and the sort of requirements an organization
could have of a deployment solution to enable a large scale rollout of Vista.

1.2.1 Why Vista?
Microsoft Vista is here, and chances are it is coming to your organization sooner
than you think. Many organizations are expecting to make a move towards Vista
within a year. The larger the organization, the higher the probability that this will
occur.

This significant commitment in time and expense is driven by a variety of factors
that include much needed features introduced in Vista and the realities of waning
support for older versions of Windows.

While enhancements in user experience like Vista's Aero™ Glass interface have
monopolized the marketing spotlight, it is enhancements under the covers that
are motivating enterprise customers to upgrade. Vista introduces a new
developer platform, .NET Framework 3.0 that enables faster development of
applications that will have better interfaces, better integration with other
applications, and better code in general. .NET Framework is comprised of key
components that include the Windows Workflow Foundation (WWF), which
makes Vista the first OS to embed a workflow development and runtime
environment, and the Windows Communication Foundation (WCF) that


dramatically simplifies the way connections between services are defined and
managed.

Perhaps the most important innovation driving enterprise adoption of Vista is
enhanced Security. Vista is the first operating system Microsoft has built from
design to release using the Security Development Life cycle (SDL) under their
Trustworthy Computing Initiative. Immediately beneficial security enhancements
include User Account Control that eliminates the need for average users to log in
with Administrator privileges and by default grant that privilege to every
application, virus, or other form of malware they intentionally or inadvertently
launch. In addition, Vista introduces a multi-tiered rights management and
encryption technology (BitLocker™) that protects data on the disk, even if the
disk is inside a stolen mobile computer. These are only a few of the security
enhancements in Vista that represent the quantum leap in integrated client
security that the enterprise has been waiting for.

Beyond the innovations Vista offers as a motivation to upgrade, there is also the
fact that older versions of Windows are becoming less supportable. With
Windows 2000 already out of mainstream support and losing critical update
support in 2010, and the launch of Vista starting the two year countdown to the
end of mainstream support for Windows XP, upgrade is inevitable. If your
enterprise may be one that falls into this group, starting to plan and test now is
your best defense against unmanageable complexity and unpredictable costs.

1.2.2 A deployment project
It is estimated that a project of 12-18 months is required to develop and test a
Vista Standard Operating Environment (SOE) in a corporate environment. The
larger the environment the longer and more complex the project. This sort of
project would include phases such as the following:
1. A full audit of all applications in use by all users within the organization.
To be able to plan the testing of all the SOE applications it is important to
quantify them all, prioritize, and plan with certainty. Being presented with 10
untested applications just before the rollout would unpleasantly impact the
project schedule.
2. Testing of all SOE applications for compatibility with Vista.
With the new security enhancements within Vista, it is probable that a
percentage of current applications will not work. Some of these will of course
be patched by their vendor to make them compatible, but of course the
custom applications written in house or by a contracted company will require
an explicit effort applied to make them compatible. This project phase has the
potential to be the most time consuming and least satisfying, as old but


important applications may not work in Vista and may have to be worked
around.
3. The development of a deployment methodology.
When rolling out a change of this magnitude to any organization, a rock solid
deployment methodology is crucial. Obviously an automation tool to deliver
an image is a part of the methodology, but what sort of image will that tool
deploy. There are three commonly used image types to consider:
– Thick Images are large images that contain the complete operating
system, all drivers, and core applications. Simple image creation enabled
by simple tools has made thick images the most common form of image;
however, it is at the expense of high-maintenance costs. Because thick
images contain so much target specific configuration, diverse
environments need to create and manage many large images to satisfy
the needs of their user population. When any small component of an
image must be changed (for example a security policy upgrade to the
firewall or virus scanner definitions), the entire image must be manually
rebuilt. The result is many large images taking up large amounts of
maintenance resource and disk space and large amounts of bandwidth
during deployment.
– Thin Images evolved as a reaction to the high total cost of thick images,
but because of the limitations of the simple imaging tools, they created as
many problems as they solved. Thin Images exclude core applications,
which must then be deployed using another software distribution system
after first boot of the base image. The benefit is fewer, smaller, more
generic based images to store and deploy thus saving disk space and
network bandwidth, and subsequent changes to an image or core
application results in far less image regeneration. End-to-end deployment
is now slower and requires a software distribution system and scripting to
complete. Actual bytes deployed will likely be more than in thick images
because of duplication of files in the application install and OS install,
although the install is spread out over a longer period of time. Note that not
having all applications deployed at first boot introduces security risks.
– Hybrid Images offer the best of thick and thin images without the
disadvantages. Advanced hybrid imaging systems separate drivers and
applications from OS images and store them in a file-based repository. At
deploy-time the correct drivers are automatically selected and injected into
the image, the correct updates and core applications are loaded into the
image, and the resulting image is deployed to the target—all before first
boot. This allows an organization to maintain as few as one universal
image that automatically adapts to each target at deploy-time when the
minimum number of files possible is deployed over the network. The result
is minimal disk space, minimal network bandwidth, and a system that
allows modification to driver or application configuration without the need


to generate and catalogue a new image. The most advanced hybrid
imaging systems go a step further by providing a policy-based
configuration capability. This allows the image to be adapted by global
policies as well as physical attributes of the target. For example, a policy
such as "deploy ThinkVantage Access™ Connection on Lenovo laptops
only" would ensure that redundant software is not deployed on other
brands of laptop. The challenge for the enterprise is that very few image
management systems on the market support this advanced form of
imaging.
4. The development of a user data migration strategy.
The migration to Vista will not be viewed as a success if your users lose data.
Despite this, it does not make sense to migrate all aspects of a user’s existing
configuration. Over time, most user desktops get cluttered with unused disk
shares, defunct network printers, and configuration changes that were
motivated by idiosyncrasies in the original operating system environment.
Additionally, as application compatibility may require the upgrade or
replacement of some applications, some preferences and configuration data
may be redundant in the new desktop environment. As a result, blind
migration of all existing "personality" may not be the right approach to take. A
fresh OS install is an opportunity to clean house, but this takes planning.
Determine what data and configuration is important to your users and
acceptable under your current security policy, and put the tools and
processes in place to migrate them cleanly to the new system. Many settings
are predictable (for example the location of the target computer dictates
which printers or disk shares should be configured) and the right deployment
tool can recreate the correct settings based on current IT and security policy
rather than migrate potentially incorrect or out-dated settings from the existing
desktop configuration. This is an important philosophical distinction to
consider when selecting an image management system. Some are better
aligned with the "migrate existing settings regardless if they are correct"
philosophy, and others align better with the "recreate clean settings from
current IT policy" philosophy.

1.3 Requirements for a tool to assist the deployment
effort
Following is a list of criteria that can be used in the assessment of a deployment
tool.


1.3.1 Time to value
How long it takes to start getting significant improvements in efficiency in your
migration process is key to the over all performance of your image management
system. Many systems management products either remain on a shelf or are
never implemented to their full potential because of the complexity of their
installation and configuration. Consider the following aspects of the system's
Time to Value.
1. How long does it take to install the product and start using it in your migration
planning process? Will installation take 30 minutes? Or 30 days?
2. Is the system an integrated single-vendor solution that provides fully
automated end-to-end deployment of desktops from Wake-on-LAN to BIOS
configuration, RAID configuration, disk partitioning, OS/driver/application
deployment, offline servicing, user data migration through to user
configuration, and first boot? Or does the system leave major aspects of
image creation and deployment to manual intervention or other 3rd party
tools?
3. Does the system consist of a single-product install providing you with all the
functionality you will require in both test and full-scale production deployment
(native multicast, USMT integration, native PXE, native configuration
database, and so forth)? Or does it consist of multiple components, each
carrying additional purchase costs, additional implementation time, additional
interface and management training, and additional infrastructure?
4. Does the system scale to tens of thousands of targets after the initial simple
installation, or will you have to purchase, install, integrate, and configure
additional enterprise product modules?
5. Does the product have a single, simple intuitive interface that spans all
product functions, or does it require that you learn multiple different interfaces
and jump between them during the planning, testing, and deployment
processes?
6. Does the system provide rules-based deployment configuration? For
example, does it support the ability to define a rule such as: "If target location
is France, set keyboard to French", or "If target is Vista, deploy Acrobat®
7.0"? At deploy-time, the system should then assess the target against all
such rules and adapt the configuration accordingly. This rules-based
capability dramatically reduces the time required to configure the images for
large and diverse populations. Without this capability, each target image
would have to be manually configured.

Note: This capability is only possible if the system supports advanced hybrid
images.


7. Does the system support advanced hybrid images allowing you to start
deploying diverse systems after creating a single-universal OS image? Or
does the product require that you create many specific thick images before
you can start testing against a diverse community of targets? Or does the
product require that you also implement a software distribution system before
you can start deploying applications on top of thin images?

1.3.2 Resource and maintenance efficiency
This selection criteria assesses the image management system's impact on your
system’s management and infrastructure costs and complexity. It is important to
consider how the system consumes your infrastructure, how it impacts your
normal operations, and how much systems management workload it generates.
1. Does the system conserve bandwidth by providing multicast as a native
feature? With multicast, a single bit stream over your network can update
many targets simultaneously. Without multicast, each target needs its own bit
stream to pass through your network. The difference in impact on your
network infrastructure and your normal operations is orders of magnitude.
2. Does the product support advanced hybrid images that enable a single,
compact universal image to do the work of many large, thick images? The
disk space required by a thick image-based product will be orders of
magnitude greater. Maintaining many thick images also has a significant
impact on image maintenance as any minor change to a driver, OS, or
application configuration can require the regeneration of dozens of images.
Does mitigating these resource inefficiencies mean implementing a thin
image strategy requiring an additional investment in a software distribution
system to deal with core applications?
3. Are the images stored in a single-instance file-based repository that
conserves disk space by storing each OS or application file only once in the
deployment repository. Or does the system store many duplicate
sector-based images or multiple copies of the same file-based image
components thus wasting storage capacity?
4. Does the system support distributed, automatically synchronized deployment
servers that can sit in distributed network segments closer to specific groups
of targets? Does the system provide this functionality in the base product
without requiring an additional investment in product license and
implementation effort? This capability can dramatically reduce the
performance impact and capacity required at gateways, routers, and over
wide area networks.


1.3.3 Flexibility
As your choice of unified image management system is likely one you will have
to live with for years to come, it is important that it is flexible enough to adapt to
your changing requirements over time.
1. Will the system provide a single-product experience for all of your
heterogeneous targets (for example Windows, Linux, Unix) now and in the
future? Or will you require additional image management systems to support
deployment and maintenance of your non-Windows targets?
2. Can the system be implemented on a server platform you currently support
(Windows, Linux, AIX®, Solaris, FreeBSD, Mac OS-X, AIX) or does it require
that you procure and maintain a nonstandard platform in your systems
management environment?
3. Is the product open, providing a native pre-installation environment and
image format, and supporting Microsoft WinPE and Microsoft WIM (Windows
Imaging) images? Or does the product force you to abandon Microsoft
best-practice and rely only on a proprietary pre-installation environment and
image format in all situations? In some situations, the native tools and formats
may be superior, although, in others the OS vendor does know best.
4. Will the product integrate easily into any systems management ecosystem,
seamlessly providing an image management foundation to any vendor's
holistic provisioning solution? Or does the product restrict its interfaces in an
attempt to force you to build on its foundation with only the same vendor's
systems management portfolio?
5. Does the vendor that supplies the product also provide a portfolio of
integrated provisioning and systems management products if you are looking
for a simple path to increase the sophistication of your automation
infrastructure?

1.3.4 Security
Mitigating security risks is a top-3 budget item for most enterprise IT
organizations. Introducing new security risks with the image management
system results in subsequent cost and effort to provide perimeter defenses
around the new exposures. The best way to avoid this collateral cost is to select
an image management system that was architected to minimize the security
exposures it introduces.
1. Has the system implemented Option-43 of the PXE specification that
prevents malicious PXE Server impersonation on your network by forcing
explicit identification of the PXE server network address? If not, an intruder
that gets access to any server on your network could deploy code that


impersonates a PXE server on your network giving the intruder the ability to
alter your desktop configurations.
2. Does the product disallow a user break of the deployment process at the
target keyboard? If not, someone with access to the target during the
deployment could gain administrator-level privileges on your network.
3. Does the product support Offline Servicing for Vista? Offline servicing allows
security updates and configuration changes to be applied to the target after
the OS and core application deployment, but before the first boot. If the
product does not support this Microsoft best practice function, the target is
exposed to many forms of intrusion and malware between first boot and the
application of the security updates.
4. Has the product implemented an encrypted transport protocol that prevents
either reading or altering the image bit stream while it is being deployed over
your network? Keep in mind, depending on your applications, these bit
streams could contain sensitive data or passwords. Many products just
support SMB (Server Message Block) or HTTP transport protocols that leave
the data exposed to malicious intruders or applications. SMB and HTTP also
require the creation of a user on the network and the storage of that user's
password on the boot media—an unnecessary security exposure.

1.4 Common OS deployment scenarios
The following three scenarios are typical of those in many corporate sites. The
aim of the scenarios is to show how Tivoli Provisioning Manager for OS
Deployment can help in times of deployment and also with day-to-day support
issues. The scenarios all assume that a corporate SOE was developed. The
common theme with all of these scenarios is that the SOE deployment
component of the task at hand has become a minor part of the process. It is now
a quick, simple step.

1.4.1 Rollout of new desktop hardware and SOE
A multinational organization decides to upgrade their workstation fleet and SOE.
They enter into a contract with a large hardware supplier to supply 15,000
desktop PCs of three different specifications and 5,000 laptops of two different
specifications. The hardware supplier is contracted to supply the workstations
directly to their final destination across three continents into 25 sites.

The organization has spent the previous 12 months developing their Vista SOE,
their deployment methodology, and deploying Tivoli Provisioning Manager for
OS Deployment. The solution developed uses a universal system profile. The
universal system profile allows them to have one image that can be deployed to


every desktop computer and laptop. When the computers first PXE boot and
contact Tivoli Provisioning Manager for OS Deployment, an inventory is taken of
its components. Using this inventory or Bill of Materials (BOM), rules can be
established to select the appropriate drivers to inject and software to install. For
example, the drivers for a desktop computer are different than those required by
a laptop computer. Based on the model number of the computer and the PCI,
Tivoli Provisioning Manager for OS Deployment can inject.

The organization allows a level of user level workstation customization, and
although the users are supposed to store all business data in specific business
systems and backed up data drives, inevitably there is data stored locally on user
workstations. To avoid upsetting the users and to make the workstation upgrade
as seamless to the users as possible the customization and data needs to be
migrated to their new machine. This is achieved by using the Microsoft User
State Migration Tool.

The deployment process for desktop computers flows as follows:
The vendor ships the computers to the site as per the deployment schedule.
The deployment is to take place overnight. At close of business, the user
state migration tool is run to back up all appropriate user settings and data.
The new workstation computers that have arrived that day are unboxed and
physically moved to the desktops in batches of 30. When 30 workstations are
plugged in they are all powered on, network boot is selected and the
computer logs into a multicast deployment.
The 4GB image deployment over a 100Mbps LAN to 30 workstations
completes in 30 minutes.
The user state migration is completed, moving the user settings back to user
workstations.

In this scenario, the bulk of the work was in planning and building of a SOE.
When it came time to actually deploy the computers, the work was very simple
consisting mainly of physically moving boxes and plugging them in.

With regard to the laptop computers, they are also shipped directly to the home
office of the proposed user. A deployment resource builds them in groups just as
with the desktop computers. When the user comes into their home office to swap
out their machine, the user state migration is run to move all settings and data.

1.4.2 Rebuild of a previously deployed user workstation
A user contacts the help desk because of issues with their workstation. The
workstation is not performing properly, and it seems like there may be an issue
with some file corruption. The help desk consultant spends 15 minutes with the


user trying to determine what the problem with the workstation is. It is apparent
that there is a problem, but a diagnosis is eluding them. The help desk consultant
decides that a workstation rebuild is the best way forward.

Tivoli Provisioning Manager for OS Deployment was rolled out across the
enterprise a few months previously. During that rollout a decision was made to
install the RbAgent, Tivoli Provisioning Manager for OS Deployment’s optional
agent, onto every workstation. RbAgent gives the Tivoli Provisioning Manager for
OS Deployment administrator, amongst other things, the ability to reboot a
computer and to force a PXE boot.

In this support instance, after gaining agreement from the user, the help desk
consultant locates the user’s computer in the management web console and
executes deploy now against it.

At the users end, the computer pops up notification that it is being rebooted for a
redeployment. The computer promptly reboots and the SOE deployment
commences.

Due to the fact that the computer is on a production network and it is during
working hours, the bandwidth consumed during the deployment is limited to 50%
of the 100Mbps available. The 4GB SOE is deployed in approximately 15
minutes.

Instead of having the issue with the computer escalated up through the support
organization and using more time up, decisive action was taken and in less than
45 minutes the user was able to once again log in and do productive work.

1.4.3 Upgrade of hardware and subsequent Vista install
An organization that upgraded its desktop workstation fleet last year decided, for
a variety of reasons, to move to Microsoft Vista. At the time of deployment last
year they believed that 512 MB of RAM per computer would be plenty of memory
for the foreseeable future. Unfortunately this was not the case and so now they
are going to have to add another 512MB memory module to each machine.

Having deployed Tivoli Provisioning Manager for OS Deployment for their
upgrade last year they are well placed to complete this piece of work at their four
100 workstation sites overnight at one site per night using three human
resources.

Following is the upgrade process:
As all the workstations are already defined within Tivoli Provisioning Manager
for OS Deployment, it is a simple task of binding the new Vista profile and the
rollout deployment scheme to all the workstations. This is done.


After each computer is opened and has its RAM upgraded, the computer is
rebooted and F12 is pressed to force a network boot.
As the computer is bound to the SOE the computer joins a rolling
non-synchronized multicast deployment scheme. This scheme ensures
maximum efficiency of concurrent data transfer but without the necessity to
synchronize computers. The deployment is completed overnight as planned.


2

Chapter 2. Architecture and
deployment scenarios
This chapter presents two case studies for the implementation of Tivoli
Provisioning Manager for OS Deployment:
A small implementation on a single LAN.
A large enterprise with multiple subnets in the main office, remote sites
connected via lower speed communication links, and the sort of security
scrutiny that characterizes large organizations today.

Subjects such as server sizing and placement, image replication, driver injection,
unicast and multicast, firewalls, and security considerations are discussed.
These are the sort of subjects that are not explicitly discussed in the Tivoli
Provisioning Manager for OS Deployment user guide, but are of great
importance when designing an implementation of a tool in a production
environment. The chapter is broken into the following sections:
“Tivoli Provisioning Manager for OS Deployment features” on page 20
“Architecture” on page 22


2.1 Tivoli Provisioning Manager for OS Deployment
features
Following are the major features of Tivoli Provisioning Manager for OS
Deployment and a short description of the features. It is these features that make
Tivoli Provisioning Manager for OS Deployment such an indispensable tool for
use during the life cycle of computer systems.
System cloning
Tivoli Provisioning Manager for OS Deployment incorporates the ability to
capture a file-based clone image of a target workstation. Using Tivoli
Provisioning Manager for OS Deployment’s built-in Pre-boot eXecution
Environment (PXE) server to boot the target system, it is possible to take a
cloned image of that system from the Tivoli Provisioning Manager for OS
Deployment Web console. This image is stored on the Tivoli Provisioning
Manager for OS Deployment server and is referred to as a profile.
Driver injection
Tivoli Provisioning Manager for OS Deployment includes the ability to add a
driver to an image as the image is being deployed to a computer. This feature
leads to the ability to create a universal system profile that in turn reduces the
number of images that need to be managed.
Software deployment
Tivoli Provisioning Manager for OS Deployment includes the ability to create
software packages that can be deployed along with the OS image.
Universal system profile
The universal system profile is the ability provided by Tivoli Provisioning
Manager for OS Deployment to support many different computer models and
configurations with one image. This is achieved by the automated addition of
various driver and software packages during image deployment.
Microsoft Vista support
Microsoft’s latest and greatest operating system is supported by Tivoli
Provisioning Manager for OS Deployment in unattended setup and cloning
modes.
No touch build capability
Tivoli Provisioning Manager for OS Deployment has features that enable a
true no touch build capability. Whether set to boot from the hard disk or the
network, Tivoli Provisioning Manager for OS Deployment can be configured
to take control of the target system and to deploy a profile.
Unattended setup
Tivoli Provisioning Manager for OS Deployment supports the unattended
setup mode of installation. In this feature all of the parameters that need to be
provided to the installer during the OS installation are predefined in the Tivoli


Provisioning Manager for OS Deployment server and fed to the installer
during the installation. This type of installation is best where a one-off
installation is going to be made or where installation to a number of different
hardware types requires an investment of time to build a master image and all
of the appropriate drivers and or application packages.
Unicast and multicast image deployment
In Tivoli Provisioning Manager for OS Deployment, profiles, or what is being
deployed, are defined separately to how the profile is to be deployed. How the
profile is to be deployed is defined in what is known as a deployment scheme.
it is in the deployment scheme that you can define the communication method
between the server and client. This can be unicast or multicast. Generally,
individual workstation and server builds are done using unicast, while builds
and batches of workstations use multicast, for the time and network
bandwidth savings that it offers.
Adjustable network bandwidth utilization during build
Deployment Schemes also offer the ability to limit the amount of network
bandwidth that is used during a deployment. This is very useful when a
deployment is being executed over a LAN during the business day. An
unlimited deployment has the capability to really slow the network segment
down as it could potentially use all available bandwidth; however, if you
limited the bandwidth to say 50Mbps on a 100Mbps LAN it could only ever
absorb half the available bandwidth.
Highly efficient image storage
By using an MD5 (Message Digest 5) algorithm to individually identify each
file being stored in the image repository, it is possible to eliminate the need to
store duplicates of any file. What this means is that one Windows XP image
may take 3GB of storage space, but two variations of an XP image could take
less than 4GB. This efficiency of storage also translates to less image data
needing to be replicated between servers in larger implementations.
Build from DVD
In some instances, a workstation that needs to be built may be at the end of a
64Kbps link, or worse. Attempting to install a 4GB image in a case like this is
impractical. The data transfer, if all went well, would take more than 7 days. In
an instance like this it is possible to cut a DVD of the image and deployment
scheme, ship it to the site, then boot from that DVD and deploy the image
from the DVD.
Boot from CD/DVD
If the network card, in a particular target system, does not support PXE boot,
or if PXE is not allowed on a network, it is possible to build a boot CD or DVD
on the Tivoli Provisioning Manager for OS Deployment server, and use it to
boot the target computer and connect it to the Tivoli Provisioning Manager for
OS Deployment server to have an image deployed.

Chapter 2. Architecture and deployment scenarios 21

Network sensitive image replication
The replication of workstation and server images around a WAN is a
controversial subject. Many organizations like to have full control over all data
on their network. Because of this Tivoli Provisioning Manager for OS
Deployment comes with the following two methods to replicate data between
servers:
– Scheduled, bandwidth controlled replication
This option allows you to set up a replication schedule between servers
and to dictate the maximum bandwidth that can be used by that
replication.
– Command line export utilities
Through the use of command line utilities, it is possible to produce
different files containing all changes since a previous checkpoint. These
files can then be moved to the slave servers using the corporate software
distribution tool or burnt to a DVD and physically moved between servers.
Redeployment
This feature provides the ability to place one or more reference images into a
hidden partition on the computer. During the system boot it is possible to do
one of the following:
– Boot the system off the current image on the hard drive.
– Do a quick clean of the currently deployed image against the reference
image.
– Do a full restore of the reference image.
Using this feature it is possible to effectively have a fresh image deployment
every day for the optimum performance of a system.

2.2 Architecture
We start our Tivoli Provisioning Manager for OS Deployment architecture
discussion with some design considerations. These are subjects that could be
important in understanding how the product works, and how it fits into a larger
corporate environment. The subjects covered are by no means a conclusive list.

2.2.1 Design considerations
This section aims to describe various items and product features that you should
consider when designing a Tivoli Provisioning Manager for OS Deployment
implementation. Many of the items are quite obvious but warrant discussion and
further explanation; likewise, others are less obvious and may assist a designer
in reaching an appropriate design. While the following list is quite


comprehensive, it should not be considered the definitive list of considerations as
every organization has its own set of idiosyncrasies to take into account. Many of
the subjects have links through to section two of this book, which contains more
detailed step-by-step guides to Tivoli Provisioning Manager for OS Deployment
features.

Unattended setup
Unattended setup of a Windows or Linux operating system entails the provision
of all the parameters required in the setup of the operating system by the Tivoli
Provisioning Manager for OS Deployment. Unattended setup is a more time
consuming method of deploying an operating system and cannot be used on the
same scale that cloning can. However it is the easiest type of deployment profile
to set up. All activities take place on the server via the Web interface. A full
description of how to set up an unattended setup deployment profile can be
found in Chapter 4, “Installing pre-Vista systems” on page 137.

An advantage of an unattended setup profile is that it is a more generic
installation, because the setup program detects the hardware and peripherals
present and detects if a driver is available, and then installs it. The important task
that the deployer has is to ensure that all the necessary drivers are available.

An unattended setup can be a good way to build an initial system for cloning. It is
also very good for building systems in an environment where the hardware has
large differences.

Figure 2-1 on page 24 shows the potential inputs to an unattended setup. This
instance includes the original files and parameters such as the license key, host
name, administrator account details, and the domain to join. It also includes a
driver package and a software package.


Driver
Unattended package
install Driver
Parameters package
Software
Package

Operating system
installation files

Result = an OS setup in
unattended mode

Figure 2-1 Unattended setup

Cloned image
Cloning is a major feature of Tivoli Provisioning Manager for OS Deployment and
in conjunction with deployment schemes gives the product its versatility. Cloning
is a fairly simple process, but it does take more set up than an unattended
operating system setup. The process to clone a machine is as follows:
1. Start with a reference machine that is representative of the different systems
to which you are going to deploy.
2. Clean the machine. By this we mean empty the recycle bin, disconnect
network drives and printers, close all applications, and delete all temporary
files and caches.
3. Run sysprep. Sysprep is Microsoft’s utility for preparing the operating system
for duplication. It clears out many of the internal system settings that identify
that instance of the operating system. When the workstation is booted for the
first time after deployment, Tivoli Provisioning Manager for OS Deployment
supplies all the parameters required to complete the mini setup, and give this
instance of the operating system its personality.


4. Boot the workstation using the network as the boot device, and then from the
Tivoli Provisioning Manager for OS Deployment Web GUI start the
administrator toolkit. This allows you to capture the image.

A full and detailed description of the creation of a cloned image can be found in
4.4, “Creating an unattended profile for Windows 2000” on page 171.

As you can see there are more steps involved in preparing a cloned image, but
when it comes to the deployment of the image it is much faster and can be
deployed concurrently to many more systems.

Figure 2-2 shows the cloning process. The snapshot of the reference personal
computer (PC) is copied to all the computers being built along with parameters
such as the license key, host name, administrator account details, and the
domain to join. It also includes two driver packages and a software package to
further customize the installation.

Reference PC

Parameters
Driver
Software
Package package

Driver
Package

Snapshot is combined
with parameters and
packages at build time
to rapidly apply a
personality to multiple
computers concurrently

Tivoli Provisioning
Manager for OS
Deployment server takes
a "snapshot" of the
reference PC

Figure 2-2 Cloned systems

Universal system profile
A universal system profile is a cloned image that was prepared with all drivers for
disk types and hardware abstraction layer (HAL) variants that are used in the


Deployment guide series tivoli provisioning manager for os deployment v5.1 sg247397

Deployment guide series tivoli provisioning manager for os deployment v5.1 sg247397

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (15)

En vedette

En vedette (6)

Similaire à Deployment guide series tivoli provisioning manager for os deployment v5.1 sg247397

Similaire à Deployment guide series tivoli provisioning manager for os deployment v5.1 sg247397 (20)

Plus de Banking at Ho Chi Minh city

Plus de Banking at Ho Chi Minh city (20)

Dernier

Dernier (20)

Deployment guide series tivoli provisioning manager for os deployment v5.1 sg247397