Deployment guide series tivoli provisioning manager for os deployment v5.1 sg247397
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 2,597 views

 

Statistics

Views

Total Views
2,597
Views on SlideShare
2,597
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • Front coverDeployment Guide Series:Tivoli Provisioning Managerfor OS Deployment V5.1Insider’s Guide to TPM for OSDeploymentLearn how to migrate to VISTAeasilyBest practices for largedeployments Vasfi Gucer Damir Bacalja Dominique Bertin Richard Hine Scott M Kay Francesco Latinoibm.com/redbooks
  • International Technical Support OrganizationDeployment Guide Series: Tivoli ProvisioningManager for OS Deployment V5.1May 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 ADPSchedule Contract with IBM Corp. View slide
  • Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi The team that wrote this Redbooks publication . . . . . . . . . . . . . . . . . . . . . . . . . xi Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivPart 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Part 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 View slide
  • 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232iv Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 5.3.3 Configuring the System profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2415.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Chapter 6. Installing Linux systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2636.1 Introduction and general requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 2646.2 Creating an unattended setup profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 2656.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2836.4 The deployment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2866.5 Cloning a machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 6.5.1 Capturing the image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 6.5.2 Customizing the captured profile. . . . . . . . . . . . . . . . . . . . . . . . . . . 2976.6 Deploying the cloned profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299Chapter 7. Common deployment features . . . . . . . . . . . . . . . . . . . . . . . . 3037.1 Configuring RAID arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 7.1.1 Building the bootable DOS diskette . . . . . . . . . . . . . . . . . . . . . . . . 3057.2 Software package rules and bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 7.2.1 Binding software packages to deployment schemes . . . . . . . . . . . 319 7.2.2 Advanced binding scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3247.3 Collecting inventory from the target machines . . . . . . . . . . . . . . . . . . . . 3287.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. . . . . . . . . . . . . . 3417.5 Understanding the host boot settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 3457.6 User administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 7.6.1 Creating the authentication domain . . . . . . . . . . . . . . . . . . . . . . . . 353 7.6.2 Setting user permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355Chapter 8. Integration and collaboration with other Change Management products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3598.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455Part 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465vi 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471Estimating 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478Appendix B. Sample Statement of Work for Tivoli Provisioning Manager for OS Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479Building 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 Contents vii
  • viii Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • NoticesThis 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. Consultyour 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 IBMproduct, program, or service may be used. Any functionally equivalent product, program, or service thatdoes not infringe any IBM intellectual property right may be used instead. However, it is the usersresponsibility 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 licenseinquiries, 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 suchprovisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimerof 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 madeto the information herein; these changes will be incorporated in new editions of the publication. IBM maymake improvements and/or changes in the product(s) and/or the program(s) described in this publication atany time without notice.Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 withoutincurring any obligation to you.Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirmthe accuracy of performance, compatibility or any other claims related to non-IBM products. Questions onthe 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 themas 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 businessenterprise is entirely coincidental.COPYRIGHT LICENSE:This information contains sample application programs in source language, which illustrate programmingtechniques on various operating platforms. You may copy, modify, and distribute these sample programs inany form without payment to IBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operating platform for which thesample 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
  • TrademarksThe 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 Corporationand/or its affiliates.ITIL is a registered trademark, and a registered community trademark of the Office of GovernmentCommerce, and is registered in the U.S. Patent and Trademark Office.Adobe, Acrobat, and Portable Document Format (PDF) are either registered trademarks or trademarks ofAdobe Systems Incorporated in the United States, other countries, or both.Java, JDBC, JDK, J2EE, Solaris, Ultra, and all Java-based trademarks are trademarks of SunMicrosystems, 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 inthe United States, other countries, or both.i386, Intel, Pentium, Xeon, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registeredtrademarks 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 productsxii 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 USABecome 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.htmlComments 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-5400xiv Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Part 1Part 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.© Copyright IBM Corp. 2007. All rights reserved. 3
  • 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 cycle4 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • There are many product suites on the market today that can enable or automatethese tasks and a few that claim to do it all. Most organizations, however, alreadyhave mature tools and processes in place for many of the tasks in the life cycleand are not about to rip and replace their existing solution unless there is a verygood business case to do so. This is where Tivoli Provisioning Manager for OSDeployment offers an excellent opportunity. Tivoli Provisioning Manager for OSDeployment 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 IBMDirector. Tasks and Activities within the Device Configuration Lifecycle TIVOLI PROVISIONING MANAGER BARE METAL OS DEPLOYMENT FOR OS DEPLOYMENT FULL AUTOMATION 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 MakingFigure 1-2 Tivoli Provisioning Manager for Operating Systems role in the configurationlife cycleThe core capability of Tivoli Provisioning Manager for OS Deployment is theability to intelligently automate the deployment of operating systems. Thiscapability extends from the many flavors of Microsoft® Windows, through SUSEand Red Hat Linux to Sun Solaris™. The deployment of an operating system isthe one item in the configuration life cycle that every single computer willdefinitely 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.6 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Tivoli Provisioning Manager for OS Deployment also touches other parts of thedevice configuration life cycle with functionality that enables the core OSdeployment functionality, as can be seen in Figure 1-3. Tasks and Activities within the Device Configuration Lifecycle TIVOLI PROVISIONING MANAGER Bare Metal OS Deployment FOR OS DEPLOYMENT DEPLOYMENT ENABLING FUNCTIONALITY 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 MakingFigure 1-3 Deployment enabling functionality of Tivoli Provisioning Manager for OSDeployment 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 Chapter 1. Introduction to image management 7
  • 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 Vistas 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) that8 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 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 Chapter 1. Introduction to image management 9
  • 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 need10 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 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 deploymenteffort Following is a list of criteria that can be used in the assessment of a deployment tool. Chapter 1. Introduction to image management 11
  • 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 systems 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.12 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 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 systems 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. Chapter 1. Introduction to image management 13
  • 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 vendors 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 vendors 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 that14 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 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 users 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 Chapter 1. Introduction to image management 15
  • 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 the16 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 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. Chapter 1. Introduction to image management 17
  • 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.18 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 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© Copyright IBM Corp. 2007. All rights reserved. 19
  • 2.1 Tivoli Provisioning Manager for OS Deploymentfeatures 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 Tivoli20 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Provisioning Manager for OS Deployment server and fed to the installerduring the installation. This type of installation is best where a one-offinstallation is going to be made or where installation to a number of differenthardware types requires an investment of time to build a master image and allof the appropriate drivers and or application packages.Unicast and multicast image deploymentIn Tivoli Provisioning Manager for OS Deployment, profiles, or what is beingdeployed, are defined separately to how the profile is to be deployed. How theprofile 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 methodbetween the server and client. This can be unicast or multicast. Generally,individual workstation and server builds are done using unicast, while buildsand batches of workstations use multicast, for the time and networkbandwidth savings that it offers.Adjustable network bandwidth utilization during buildDeployment Schemes also offer the ability to limit the amount of networkbandwidth that is used during a deployment. This is very useful when adeployment is being executed over a LAN during the business day. Anunlimited deployment has the capability to really slow the network segmentdown as it could potentially use all available bandwidth; however, if youlimited the bandwidth to say 50Mbps on a 100Mbps LAN it could only everabsorb half the available bandwidth.Highly efficient image storageBy using an MD5 (Message Digest 5) algorithm to individually identify eachfile being stored in the image repository, it is possible to eliminate the need tostore duplicates of any file. What this means is that one Windows XP imagemay take 3GB of storage space, but two variations of an XP image could takeless than 4GB. This efficiency of storage also translates to less image dataneeding to be replicated between servers in larger implementations.Build from DVDIn some instances, a workstation that needs to be built may be at the end of a64Kbps link, or worse. Attempting to install a 4GB image in a case like this isimpractical. The data transfer, if all went well, would take more than 7 days. Inan instance like this it is possible to cut a DVD of the image and deploymentscheme, ship it to the site, then boot from that DVD and deploy the imagefrom the DVD.Boot from CD/DVDIf 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 DVDon the Tivoli Provisioning Manager for OS Deployment server, and use it toboot the target computer and connect it to the Tivoli Provisioning Manager forOS 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 quite22 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • comprehensive, it should not be considered the definitive list of considerations asevery organization has its own set of idiosyncrasies to take into account. Many ofthe subjects have links through to section two of this book, which contains moredetailed step-by-step guides to Tivoli Provisioning Manager for OS Deploymentfeatures.Unattended setupUnattended setup of a Windows or Linux operating system entails the provisionof all the parameters required in the setup of the operating system by the TivoliProvisioning Manager for OS Deployment. Unattended setup is a more timeconsuming method of deploying an operating system and cannot be used on thesame scale that cloning can. However it is the easiest type of deployment profileto set up. All activities take place on the server via the Web interface. A fulldescription of how to set up an unattended setup deployment profile can befound in Chapter 4, “Installing pre-Vista systems” on page 137.An advantage of an unattended setup profile is that it is a more genericinstallation, because the setup program detects the hardware and peripheralspresent and detects if a driver is available, and then installs it. The important taskthat 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 isalso very good for building systems in an environment where the hardware haslarge differences.Figure 2-1 on page 24 shows the potential inputs to an unattended setup. Thisinstance includes the original files and parameters such as the license key, hostname, administrator account details, and the domain to join. It also includes adriver package and a software package. Chapter 2. Architecture and deployment scenarios 23
  • 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.24 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 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 in4.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, butwhen it comes to the deployment of the image it is much faster and can bedeployed concurrently to many more systems.Figure 2-2 shows the cloning process. The snapshot of the reference personalcomputer (PC) is copied to all the computers being built along with parameterssuch as the license key, host name, administrator account details, and thedomain to join. It also includes two driver packages and a software package tofurther 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 PCFigure 2-2 Cloned systemsUniversal system profileA universal system profile is a cloned image that was prepared with all drivers fordisk types and hardware abstraction layer (HAL) variants that are used in the Chapter 2. Architecture and deployment scenarios 25
  • organization, so that one cloned image can be sent to many hardware types and the mini setup can cater to the changes necessary for the image to work. Figure 2-3 shows a universal system profile. With the addition of appropriate driver packages the cloned image made on one type of hardware can be made to work properly with hardware of another type. For maximum efficiency in storage and ease of profile management, use a universal system profile. Parameters Driver Driver Driver Driver Driver Packages Previously created snapshot Software Software Software Software Packages Using a universal image that includes the appropriate drivers, it is possible to build many different kinds of hardware from the same image Figure 2-3 Universal system profile Driver packages Often the difference between two computer models is minimal, a BIOS version or the video card and so forth; however, the difference is enough to make the clone image captured from one computer model not work on the other. To fix this you could always capture an image from the second model and build rules to ensure that each image was only deployed on the appropriate model, or you could build and apply a driver package. A driver package is simply the driver files packaged with their identifying information and potentially a deployment rule. When the package is installed the files are automatically copied into the Drivers directory on the target system, generally after the OS files are deployed. When the system boots up and sysprep runs, the driver for the hardware is installed by the operating system.26 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • In some instances it may be desirable to install the driver package after one ofthe system reboots or in a specific order to avoid software conflicts. Thesecharacteristics are all controllable and set up in the driver package creationwizard.Using this functionality it is possible to just add driver packages to images as avendor’s hardware evolves over time. A full description of how to create a driverpackage is included in 7.4, “Device driver injection” on page 332.Software packagesLike driver packages, software packages are all the files required to deploy asoftware application bundled up for addition to a deployment; however, thedifference between the two is that a software package is executed and thesoftware is installed as opposed to a driver package that places the files into thefile system for installation by the operating system. Tivoli Provisioning Managerfor OS Deployment has the capability to install the following: A Windows application, using the Windows Installer, MSI (Microsoft Installer Package) A Linux application, using RPM (Red Hat Package Management) A Solaris application, using PKGADD A custom action on the target computer. These actions include the following: – Copy and run a single file – Execute a command – Modify a Windows registry – Create or modify a Windows INI file – Copy a single text fileUsing this capability it is possible to start to build a SOE by first deploying anoperating system and then installing software and customizing that operatingsystem. An example of the steps taken to produce a software package are in 7.2,“Software package rules and bindings” on page 315.It is important at this stage to point out that Tivoli Provisioning Manager for OSDeployment is not a software distribution tool like Tivoli Configuration Manager,Tivoli Provisioning Manager for Software, or Tivoli Provisioning Manager. It lacksmany of the features that make up a true software distribution tool.BindingIn Tivoli Provisioning Manager for OS Deployment, the term binding refers to anassociation made between two components within the system. It is possible tobind a profile to a host, a software package to a host, or a software package to a Chapter 2. Architecture and deployment scenarios 27
  • deployment scheme. These bindings can be explicit or implicit. By default when you deploy a profile to a computer, that computer is implicitly bound to that profile. If you network boot the computer again, it, by default, automatically starts loading the bound profile unless you change that behavior. You may choose to explicitly bind a profile, software, or driver packages to a host. Using rules, you can implicitly bind software packages and driver packages to host as well. More information about the options available and some scenarios appear in 7.2, “Software package rules and bindings” on page 315. Hostnames 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. Tivoli Provisioning Manager for OS Deployment offers a number of ways to register a host name within the system: 1. 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 is unacceptable 2. 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. 3. 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. More details about how to achieve this is contained in “Configuring the System profile” on page 241. 4. Let Tivoli Provisioning Manager for OS Deployment decide. Tivoli Provisioning Manager for OS Deployment will assign a hostname. Deployment schemes A deployment scheme determines how computers are installed, not what is being installed. In order to cater to the many different scenarios that occur during28 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • the deployment and redeployment of computers, Tivoli Provisioning Manager forOS Deployment offers the ability to customize how profiles are deployed.For example, during a rollout of a new fleet of computers, it may be that in astaging area 50 computers are built concurrently using a multicast protocol, andat the conclusion of the deployment the computers are shutdown before thesysprep is run because the organization decided that they want the computer tojoin a domain when it is on site. Whereas rebuilding a workstation out on abranch network would use a unicast protocol and the computer would rebootready for the user to log on when the deployment completed. This redeploymentof the profile required absolutely no action from the user apart from the removalof their hands from the keyboard. Both of these examples are deploymentschemes that optimize the way a profile is deployed for the specific task at hand.Characteristics that can be set in a deployment scheme include the following: The level of interactivity required during a deployment. Interaction ranges from none where hosts are already defined in the system to prompt the first time a system is to be deployed but not every subsequent deployment, or prompt every time a system is to be deployed or redeployed. When a profile is being deployed, by default Tivoli Provisioning Manager for OS Deployment compares the computer model that the profile was created on with the computer model it is being deployed onto. If there is a mismatch one of three behaviors can be selected: Ignore—this is for when profiles are model independent. Prompt—or when you would like an operator to decide whether it is ok to proceed. Or abort—for when you want the models to match. Data collection. Tivoli Provisioning Manager for OS Deployment by default takes an inventory of all computers it deploys. On Windows systems it can also take a software inventory. In the deployment scheme it is possible to set when the inventory is taken, before deployment, after deployment, or at each boot and whether the screen is locked or not during this process. You can set the type of information gathered, PCI inventory, DMI inventory, disk and software inventories, along with deployment logs that can be stored on the server or on the computer being deployed. Bear in mind that all inventories require database space and depending upon how many computers are being deployed, your database could grow quite large. Actions when the deployment is completed. There are the following two stages to this: – When all the files are transferred to the computer, you can have the computer shut down and complete the installation when the computer is explicitly rebooted. This could be useful when you want customizations to occur when the computer reaches its final destination. You could have sysprep run interactively, which is useful for instance if the time zone of Chapter 2. Architecture and deployment scenarios 29
  • the workstation was unknown during the build and could only be determined once it reached its final destination. Stop when sysprep is ready to run unattended, which gives the opportunity to move the computer to the user environment for final customization, or joining of a domain when sysprep is complete and the computer is ready for use. – The second stage, after the points listed above, is for you to choose whether the system shuts down, reboots, or just displays a green banner announcing completion. Network usage. Understanding these settings is important. There are three options: – Unicast, used for single deployments or where multicast is either not allowed or not supported. With unicast, as the number of concurrent computers being deployed increases, network performance decreases rapidly. A unicast is effectively a private conversation between two computers. If the profile to be deployed was 2GB, the Tivoli Provisioning Manager for OS Deployment server has to serve up 2GB of data and that 2GB has to traverse your network. If you were deploying three computers concurrently using the same profile, the server has to maintain three sessions doing the same thing, queue and process the 2GB three times and that resultant 6GB has to traverse the network via one network card. Now with a reasonable sort of server on a gigabit network that is probably not a big deal, but on a 10MB network it means at least one hour and 40 minutes of saturated network, and if you added any more sessions you would probably find that the bottleneck in the system was your server. Figure 2-4 on page 31 shows a unicast to four computers, each computer receives a separate, directly addressed data transmission. The server has to work four times harder and the network carries four times the traffic than it does during a single build.30 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Server The packets on the network are addressed to individual computers, so only the specific addressee can accept the packet. With unicast each computer has a private communication with the server PC 1 PC 1 PC 1 PC 1 PC 2 PC 2 PC 2 PC 2 PC 3 PC 3 PC 3 PC 3 PC 4 PC 4 PC 4 PC 4Figure 2-4 Unicast It is for this reason that multicast was developed. Multicast in Tivoli Provisioning Manager for OS Deployment was designed for robustness as opposed to speed. The aim is to get the transfer done to all targeted clients on the first attempt during a deployment, thus lowering project risk. The way it works is as follows: On each client computer the files that are received are recorded in a special content file so that the client knows which files it has and which files it needs. The server elects one of the client computers as the master and effectively communicates with it but with other slave computers listening in on the transfer. The master controls the speed of the transfer and what is requested. Depending on the performance of the slave computers, they may be able to keep up and receive, process, and write at the same rate as the master, or if not they drop the packets. After the master finishes its transfer, an incomplete slave is promoted to the master and it starts requesting files according to what is required in its content file. All the other incomplete slaves listen in and accept packets that they require. This process continues until all the client computers have all required files. So lets carry our unicast example forward into our multicast explanation and distribute our 2GB image to three computers. One of the computers is of a lower performance specification than the other two. There is a 2GB Chapter 2. Architecture and deployment scenarios 31
  • transfer to the machine designated by the server as the master client. The first slave keeps up with the master; therefore, it receives and processes all the packets and finishes at the same time as the master. The third computer however could not keep up. Its internal speed is just not the same as the other two and as such it could not cope with the data stream. It managed to retain only 80% of the 2GB and therefore requires a retransmission of 20% or 400 MB of the data. The server serves up this catch up data and then all computers are completed. This resulted in only 2.4GB of data traversing the network instead of 6GB as with a unicast. Because of the retransmission it takes longer than a unicast; however, the network utilization is markedly less. The implementation of multicast in Tivoli Provisioning Manager for OS Deployment starts to show speed efficiency at around 10 clients. Most efficiency is gained when computers of the same specification are being built together. Tivoli Provisioning Manager for OS Deployment offers the following two variants of multicast: • Synchronized multicast. With this option it is possible to have the start of transmission delay until a predetermined number of clients register with the server or a time-out period is reached. After one of these criteria is met, transmission commences. It is possible to start other clients and bring them seamlessly into the transmission after it has commenced, with the files that are missed at the start being caught up at the end. • Soft synchronization multicast is the second type of multicast. It is less efficient but good for rolling deployments. In this instance of multicast client systems do not explicitly synchronize, they just start downloading when they are ready. If multiple client systems are downloading files in parallel they automatically share the same bandwidth. Figure 2-5 on page 33 shows how multicast packets are addressed to a group. Those who opt into the group can receive the packets. Multicast puts a lower load on the server and network resources.32 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Server The packets on the network are addressed to a group, so all members of the group can accept the packet. In this way 1 packet can be accepted by many computers, reducing the amount of network traffic Group Group Group GroupFigure 2-5 Multicast Onsite deployment. Enable this feature if you want to use the advanced redeployment feature. More about the redeployment feature can be read in the section on “Chapter 10, “Redeployment and self-healing feature” on page 419”.Using these various options it is possible to cater to most deployment situationsin the most efficient way. A thorough Tivoli Provisioning Manager for OSDeployment design includes specifications for the deployment schemes to beused in the final implementation. These specifications would also highlight thenecessity for things like multicast support and the level of interaction that isexpected with each deployment type.Image replicationIt is important to have a good understanding of how file replication in TivoliProvisioning Manager for OS Deployment works, so that the effect it has on aproduction network is appreciated.How replication worksWhen a profile is captured or built with the Tivoli Provisioning Manager for OSDeployment server, the files undergo the following process: as files are sent theserver, they are uniquely identified using an MD5 algorithm. Having identified thefile the process then determines whether there is another copy of the file already Chapter 2. Architecture and deployment scenarios 33
  • in storage on the server. If there is, the existing file is referenced in the new profile and if not, the process stores the file in a 128MB file repository block and its corresponding table of contents file. There are two methods you can use to replicate images between Tivoli Provisioning Manager for OS Deployment servers: Use the built in file replication service. Manually generate change files at the command line and use another tool to move these files around the network. Built in file replication service In a multi tiered implementation, one server is designated as the master server. This is usually the server at the master site, but must be the server where profiles are inserted into the system. The other servers in the environment are designated as slave servers. When replication starts the new table of contents files are all sent to the receiving server. The receiving server then compares those table of contents files with the table of contents files it has and builds a list of all the files it requires to be up-to-date. It then sends that requirements list file back to the master server. The master server then builds a.RAD file of all these required files and commences replicating it to the receiving server using no more than the bandwidth specified in the replication setup panel. As the file repository only ever stores one copy of any specific file, subsequent to the initial replication of a particular OS all that should ever traverse the network is the delta between the existing profiles and the new profiles. This feature saves a large amount of network bandwidth. The data flow is shown in Figure 2-6 on page 35.34 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Master Server 12 11 1 10 2 9 3 3 8 4 7 5 6 .RAD File 4 .RAD File TO C li 1 st Re qd file s .RAD File 5 2 Slave 1 Table of Contents files sent to slave server at a scheduled time Server 2 List of required files is returned to the master server 3 The required files are all assembled into a .RAD file for transfer 4 RAD file is sent to the slave server 5 Slave server checks the .RAD file and then incorporates its contents into its repositoryFigure 2-6 Tivoli Provisioning Manager for OS Deployment replication data flowIn a multi tiered environment, the replication setup has to be given someconsideration as it is done on a schedule. It is important that enough time isgiven between scheduled instances for the replication to complete. In theinstance of three-tiered architecture, each predecessor must be completed priorto the successor starting. Into this equation you must factor the bandwidthlimitation you place on the replication.Command line methodTivoli Provisioning Manager for OS Deployment offers a command line interfacecalled RbAgent. RbAgent can be run from any workstation that has connectivityto the Tivoli Provisioning Manager for OS Deployment server. When executedthe RbAgent command connects back to the Tivoli Provisioning Manager for OSDeployment server, and assuming the appropriate .PAK file is present in the, bydefault, C:Program FilesCommon FilesIBM Tivolipackages directory, runs thecommand.This command line capability offers excellent integration opportunities withpreexisting tools for file transfer and configuration management, such as those Chapter 2. Architecture and deployment scenarios 35
  • already incorporated into IBM Tivoli Configuration Manager V4.2.3 FP2, IBM Tivoli Provisioning Manager, and IBM Provisioning Manager for Software. 1. To synchronize servers from the command line you need to first download the file sync.pak from the following IBM OPAL Web site: http://www.ibm.com/software/tivoli/features/it-serv-mgmt/opal.html, 2. Copy that file into the directory as stated above. 3. Stop and start the “Rembo Server” service. This will make the commands implemented in sync.pak available to RbAgent. Then the process is to use the commands available to first create a zero checkpoint of the master server. Then subsequently every time an activity of any significance takes place, another checkpoint is created. From any two checkpoints, different files containing all the file repository changes that need to be sent to a slave server can be generated. These different files are called .RAD files. A further option is the ability to break a .RAD file down into smaller .DAT files for manageability. The generated .RAD or .DAT files are transferred using your tool of choice to the target server and placed in the C:TPMFOS FilesimportAuto directory. This directory is automatically created when the Sync.PAK file is placed in the packages directory. The Tivoli Provisioning Manager for OS Deployment server checks every minute for new files. When one is found it reassembles it if it is a series of .DAT files, checks it for consistency, and then if all is ok gives it a .OK extension. The server incorporates the content of the file into the shared repository, making that content available for use in that server. A full description of the RbAgent commands necessary for replication are in 11.6, “Synchronization with the RbAgent” on page 455. Important: While the command line method of repository synchronization does give control of the replication process back to the user, the following must be noted: Manual replication using the RbAgent replicates only repository changes. Each server maintains its own database of hosts and information associated with those hosts. Keeping track of what each checkpoint represents and where target servers are up to in terms of file repository replication, are tasks that need to be incorporated into the overall replication process.36 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Profile migrationThe separation of development, test, and production environments is a longstanding IT best practice. Tivoli Provisioning Manager for OS Deploymentincorporates functions that allow for the export and import of developed profiles,software packages, and deployment schemes. This allows these objects to bemoved between environments easily and quickly.ExportUse the following steps to export a profile, software package, or deploymentscheme:1. Go to the OS Deployment screen.2. Select one of the following: system profiles screen, the software deployments screen, or the deployment scheme screen.3. At the bottom of the screen select RAD Export. This starts the RAD Export Wizard. You will be guided through a series of screens allowing you to select the items you want to export. The server will analyze the objects you want to export and approximate the size of the export file and give you the following three options for how to deal with the file: • You could download it directly to the computer you were accessing the Tivoli Provisioning Manager for OS Deployment server from. This would allow you to use it as a staging point. • You can export to a directory on the Tivoli Provisioning Manager for OS Deployment server. This may be the option you use if you have physically separate environments and need to load the file onto a removable device to move it. Or you had another tool that was going to do the physical move for you. • You can move the file directly to another machine that is running the Tivoli Provisioning Manager for OS Deployment Web extension, RbAgent. With this option, if the importing system is accessible in the network you are connected to, you could move the file directly to that computer. Tip: When working with Tivoli Provisioning Manager for OS Deployment Web extension, or RbAgent, it is important to remember that it does not resolve hostnames. You must always use an explicit IP address.ImportAt the importation end, it is almost a reverse of the export.1. Navigate to the OS Deployment screen. Chapter 2. Architecture and deployment scenarios 37
  • 2. Select one of the following: the system profiles screen, the software deployments screen, or the deployment scheme screen. 3. At the bottom of that screen select RAD Import. You are presented with the following three options for the location of the .RAD file for import: • The local computer you are working from. • The Import directory of the importing server. You may recall that one of the export options was to export to the importing server. • The IP address of a server running the Web extension where the file is located. 4. Which ever option you choose, the next step is to identify the .RAD file at the location you selected for importation. Tivoli Provisioning Manager for OS Deployment will then analyze the file and import the parts of it that it requires. Remember that it is just the files that are not already stored on the server that it will import. Tip: Accessing to the export and import functions achievable through right clicking on an item to be exported or through the use of the context menu that appears at the bottom left of the Web interface. Client boot options Tivoli Provisioning Manager for OS Deployment offers a number of options that augment the standard way a computer boots. Most computers are set up by default to boot off the hard disk. If there is no hard disk, it tries the CD/DVD drive. If that is not available, it tries for other removable devices, and if there are not any of them available, it tries for a network or PXE boot. This gives the computer the best chance of finding a bootable device. Of course most systems let you change this order, but to do that you have to access a special menu by using predefined keys at very specific times during the boot process. Another way offered to change the boot order is to press the F12 key (on many computers) at a specific time during the boot process, which takes you directly to the boot from network option. For this to be successful there has to be a PXE server available to service this request. This process is fine for someone who is comfortable with computers and in fact is usually the way bulk builds of workstations are initiated. For someone who has very little knowledge of computers, asking them to press F12 during the boot of their computer would draw a blank stare. It is this situation that is avoided with some of the options available in Tivoli Provisioning Manager for OS Deployment. After the initial build of a computer is completed you have some options about how much Tivoli Provisioning Manager for OS Deployment gets involved in the boot process.38 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Generally computers are set to boot from their hard drive after a deployment.With Tivoli Provisioning Manager for OS Deployment, however, it is possible toboot from the hard drive or network, each method having options to controlbehavior.Hard drive bootBooting off the hard drive is probably the first choice and the traditional choicethat IT departments make. Should you want to rebuild a machine at a later timedue to malfunction or upgrade, you would need to contact the user and havethem intervene in the boot process so that Tivoli Provisioning Manager for OSDeployment could boot the machine and take control remotely. This is not idealin a support situation. If you wanted a completely hands free experience for youruser, the RbAgent could be included in the standard computer build. Theinclusion of RbAgent allows the Deploy Now function within the tool to beexecuted when a redeployment is needed. Under instruction from the server,RbAgent shuts the computer down after writing a temporary master boot recordthat instructs the computer to boot from the network at the next boot. Thecomputer reboots using the network boot method, connects to the TivoliProvisioning Manager for OS Deployment server, and deploys the profile usingthe deployment scheme as selected by the operator. This method gives a fullyhands free deployment.Network bootAnother option is to set computers to boot off the network every boot, and set theaction that will be taken in the Tivoli Provisioning Manager for OS Deploymentserver. Possible actions include the following: The computer is completely ignored in the console. In this case the Tivoli Provisioning Manager for OS Deployment does not answer PXE requests (the computer times out during PXE). The computer is configured to boot on the hard disk in the console. In this case the computer boots on the disk. The computer has one or more configurations bound to it in the database (you can double-click a host to see the current bindings of that host). In this case, the computer shows a menu with the list of bound configurations. You can click one configuration to deploy it. The customized GUI in each of the configurations in the Web console can be used to change the look and feel of this boot menu (select an entry after a time-out, ask for a password). The computer has no configuration bound to it in the database. In this case a locked screen is shown.All of these options give you the opportunity to change the boot behavior of thecomputer from the Tivoli Provisioning Manager for OS Deployment console. Chapter 2. Architecture and deployment scenarios 39
  • Redeployment Within Tivoli Provisioning Manager for OS Deployment there is a function called Redeployment. This is not to be mistaken with the activity of redeploying an image to a computer. Redeployment in Tivoli Provisioning Manager for OS Deployment terms is a special deployment scheme that gives you the ability to rapidly restore an image to a computer from a hidden partition on the computer’s hard disk. The real value in this feature is for computers that fall into the following three categories: Computers that have rigidly fixed configurations such as ATMs, POS, or other embedded systems. Computers in public areas such as libraries, Internet cafes, or educational facilities. Critical systems in industries such as banking and finance, or even machines where security threats such as viruses or keyloggers/adware are a great concern. These machines can be effectively rebuilt everytime the computer is rebooted. Following is how it works: During the original image deployment to the computer, Tivoli Provisioning Manager for OS Deployment creates a hidden partition on the hard drive of the target computer. When it finishes deploying the master image on the computer, it stores a reference image into that hidden partition. It is possible to store multiple, different images in that hidden partition. Each time the system is booted, either off the hard drive or using PXE, Tivoli Provisioning Manager for OS Deployment intercepts the boot process of the computer and presents a customizable menu of the following possible actions: – Do a quick restore from the reference partition. This option just restores altered and added files to their reference. It only adds 10-15 seconds to a system boot. – Do a format and restore from the reference partition. This option takes a couple of minutes but results in a complete refresh. – Choose and deploy another configuration on the reference partition. This option takes as long as the format and restore option. – Just boot off the hard drive. Each of these options can be associated with a timer to allow for an automated action upon reboot after a time-out.40 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • With redeployment enabled in a school library or in an internet cafe, a possiblescenario is that at the end of every day all the computers are shut down. Everymorning when the computers are booted they wait 10 seconds then start doing aquick restore as the default option is automatically selected. This would ensurethat a fresh environment is available to the users everyday, devoid of adware,viruses, or caches containing inappropriate material.Server specificationThe size and configuration of a Tivoli Provisioning Manager for OS Deploymentserver should be decided after taking a number of factors into consideration.First, the number of hosts you want to define within the server. After you reach1-2000 hosts, the GUI starts to reach the limits of its navigability and becomes apractical limitation. It just takes too long to scroll through the host list. With thatsaid, if you used RbAgent, and set the implementation up so that distributionswere all triggered from the client interface this would not be an issue andscalability up to 5000 hosts on one database is easily achievable. Where anorganization’s computers exceed 2000, it would be wise to start splitting thedatabase across servers. You would still replicate all the profiles and deploymentschemes. This scenario is discussed in our large enterprise case study in 2.2.3,“Enterprise architecture” on page 55.Second, consider the amount of work the server will be doing. If it is the plan toconcurrently deploy multiple, different profiles using a unicast deploymentscheme on an ongoing basis, so a high I/O requirement, it will be necessary toensure that a disk subsystem capable of serving up this level of data is provided.This could mean the use of a RAID array, or depending on the requirement, rightup to a channel attached SAN (storage area network) solution. This type ofsolution would probably only be required on a site where a large scalecentralized build LAN was being heavily utilized.Being able to serve up data out of a disk subsystem is one thing, you also needto be able to get that data onto the network. You may want to consider multipleNICs (network inferface card) on a switched network in our extreme instanceabove, but also a high speed LAN such as 100MB or 1GB for maximum transferspeed.Third, consider memory. The minimum specification for a Tivoli ProvisioningManager for OS Deployment server is 1GB of RAM. Depending on the number ofusers and the number of concurrent builds being undertaken, extra RAM wouldbe prudent. During a computer build RAM usage can reach 500MB as the serverassembles and queues the files required. Therefore, once again how the serveris to be used, for example the number of concurrent build sessions, dictates thememory requirement. A multiuser RDBMS instead of the built in Access Chapter 2. Architecture and deployment scenarios 41
  • database will also increase the memory requirement by the amount recommended by the RDBMS vendor. Finally, consider processors. The minimum specification for a Tivoli Provisioning Manager for OS Deployment server is dual Xeon® 1GHZ processors. The server is multi threaded and so benefits from the second CPU when it is busy. At what point do you go to four processors? In our extreme example above with a SAN and dual NICs on a switched network, four CPUs would certainly be warranted assuming sufficient RAM was available as well. When specifying a build server for a deployment project you need to keep in mind that unless you are an organization that builds systems as a core competency, this server requirement will be transient, and while you can configure an extremely high performance server to fulfill your immediate build performance requirements, performance can also be improved by other simple strategies such as using multicast deployment schemes to groups of computers with similar performance, good and appropriate network infrastructure, and well built and considered profiles. PXE Preboot eXecution Environment (PXE). This is the protocol used by Tivoli Provisioning Manager for OS Deployment to remotely download the Tivoli Provisioning Manager for OS Deployment kernel necessary to boot the computer and undertake the actions to deploy an operating system onto a computer. Generally a PXE server would be on the same network subnet as the computer being deployed, but in larger installations this may not be the case. If so it is important to ensure that the “DHCP” settings on your network are correctly configured. DHCP is discussed further in “DHCP” on page 43. Network booting without PXE In some instances it may be necessary to boot a workstation without using PXE boot. This may be because the network card does not support PXE—unlikely, but possible, or more likely in a network where for a policy or security reason PXE is not available. In this instance it is possible to build a bootable CD or DVD from a computer with the RbAgent installed in it. To create the boot image, go to the directory where RbAgent is installed, by default on a Windows machine: “C:Program Filescommon filesIBM tivoliRbagent.exe” Enter: rbagent.exe -s <host_ip_address>:<host_password> rad-mkbootcd <full_path_to_boot_iso> <host_ip_address> <host_password> Where:42 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • host_ip_address = IP Address of the Tivoli Provisioning Manager for OSDeployment Serverhost_password = Password for the administrative user (usually admin) on yourTivoli Provisioning Manager for OS Deployment Server.full_path_to_boot_iso = The full path to the iso file you wish to create on themachine where you run the command including the filename.Example 2-1 rbagent.exeC:Program Filescommon filesIBM tivolirbagent.exe -s10.10.10.10:abcd rad-mkbootcd C:boot.iso 10.10.10.10 abcdIn Example 2-1there are the following two parts: First the part that allows RbAgent connection to the Tivoli Provisioning Manager for OS Deployment server: “Rbagent -s<IP_Address>:<Password>” this part tells RbAgent which server to connect to by IP address (only IP address) and the connection password. Second part: rad-mkbootcd <full_path_to_boot_iso> <host_ip_address> <host_password>, tells the rad-mkbootcd command where the ISO is to be created, the IP address and password of the server that the boot CD will try to connect to.Once booted, the behavior of the computer is identical to any PXE bootedsystem. For more information about RbAgent commands refer to 11.6,“Synchronization with the RbAgent” on page 455.DVD deploymentIn some instances computers that require deployment are at remote sites, sitesserviced by communications links not suitable for large data transfers, or just withno connectivity. These computers still form a part of an organization’s inventoryand need to be managed. In situations such as these Tivoli ProvisioningManager for OS Deployment has the capability to build an image onto a DVD orspanned across several DVDs. The DVD can be transported to the computer viamail, courier, or carrier pigeon and deployed with or without connectivity to theTivoli Provisioning Manager for OS Deployment server. A full description ofmaking a DVD deployment disk is in Chapter 9, “CD/DVD based deployment” onpage 403.DHCPThe Dynamic Host Configuration Protocol (DHCP) is a mature, well documentedprotocol that has been in use for many years. It is used by network attached Chapter 2. Architecture and deployment scenarios 43
  • devices that require an IP address, but have no dependence on that address, for example, workstations. Before the advent of DHCP, every IP device attached to a network required the administrative overhead of setting and tracking the address of every IP device on their network. One of the features of DHCP is the ability to enable various options to change the default behavior of the protocol. Things like the addresses of various services on the local network, configuration settings like timeouts, and vendor specific information. There is a list of well over 100 of these options available and detailed information can be found by searching for “DHCP options” on the Internet. Of interest to us in our discussion regarding design considerations are DHCP options 43 and 60. By default Tivoli Provisioning Manager for OS Deployment’s installer makes any required changes automatically for you; however, it is important to understand what is being changed and how it works, especially in the case of larger corporate networks where networking is never simple. In order to support PXE clients on a network, the DHCP server is usually configured in one of the following three modes: Option 60 not set, Option 43 not set Option 60 set to PXEClient, Option 43 not set Option 60 set to PXEClient, Option 43 set When option 60 nor option 43 is set, PXE clients have no clue on where the PXE server is, and they will therefore wait until a PXE server contacts them. In this mode, the PXE server must listen to DHCP discovery packets sent by PXE clients and answer at the same time as the DHCP server does. When option 60 is set to PXEClient, it means that the DHCP server knows where the PXE server is. If option 43 is not set, the PXE server is on the same computer as the DHCP server (same IP address). If option 43 is set, PXE clients must decode option 43 to know how to reach the PXE server. In most situations, option 43 does not need to be set up, because the PXE server will either listen to DHCP discovery packets (DHCPProxy) or be on the same computer as the DHCP server. However, if the PXE server is on a separate subnet (it cannot listen to DHCP discovery packets). Or if there are several PXE servers on the same subnet, option 43 is the only viable solution in order to instruct PXE clients on what to do. Option 43 is a binary buffer, containing a list of sub-options. Sub-options are packed in the binary buffer, in no specific order. Most sub-options are optional. Some examples of option 43 are in 3.1, “Server installation on Windows systems” on page 76.44 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Firewalls Table 2-1 and Table 2-2 on page 46 list the server communication ports. Table 2-1 has client communication ports. Table 2-2 on page 46 is required by the different Tivoli Provisioning Manager for OS Deployment protocols and services. Should it be required for network design or security reasons, all ports except port 69 for TFTP can be modified. TFTP cannot be modified as this specific port is part of the PXE specification.Table 2-1 Ports required for server communication Description Port Protocol Modifiable Purpose DHCP 67 UDP Yes To issue IP addresses (Dynamic Host Configuration and other network boot Protocol) information PXE BINL 4011 UDP Yes To create an (Preboot eXecution environment on a Environment)(Boot computer where a boot Information Negotiation program can be loaded Layer) TFTP 69 UDP No Protocol used to (Trivial File Transfer Protocol) (part of PXE transfer the boot specification) program to the PXE environment on a booting computer MTFTP 4015 UDP & TCP Disabled in Disabled in V5.1 (Multicast Trivial File Transfer V5.1 protocol) NBP 4012 UDP Yes For exchanging (Network Bootstrap Program) messages with the boot server FILE 4013 UDP Yes For transferring files to a computer in unicast mode MCAST 10000 - UDP Address: Yes For transferring files to (Multicast) 10500 239.2.0.1-239.2.1. multiple computers in 1 multicast m Chapter 2. Architecture and deployment scenarios 45
  • Table 2-2 Ports required for client communication Description Port Protocol Modifiable Purpose DHCP 68 UDP Yes To request and receive (Dynamic Host Configuration an IP address and other Protocol) network boot information MTFTP 8500-8 UDP Disabled in Disabled in V5.1 (Multicast Trivial File Transfer 510 V5.1 Protocol) MCAST 9999 UDP Yes To acknowledge receipt (Multicast) of Mcast packets when designated the master Remote control 4014 UDP Yes To allow the TPMfOSd (Web Interface Extension) server to communicate to the Web extension The ports that you need to open for Tivoli Provisioning Manager for OS Deployment to effectively communicate across a firewall depend on the functionality you want to use across the firewall. In a highly-secure environment, it may be best to just remove the computer that requires building or rebuilding and reconnect it after the work is done on a build LAN. An example is in a DMZ (demilitarized zone) where servers are to be built and rebuilt. It is highly unlikley that DHCP, PXE, or multicast would be available. This reduces the number of ports required on the host side to just 3, 69, 4012, and 4013. None would be required on the client side. Use Table 2-1 on page 45 and Table 2-2 as guides to help you decide which services are required and the ports you will need to open. Security As you would expect in an enterprise class systems management tool there are a variety of security options available for exploitation. Following are some of those options: Authentication against a Windows domain. With this option you can specify an Active Directory® server to authenticate against. Within Tivoli Provisioning Manager for OS Deployment you can define categories of users such as administrators, deployers, operators or profile developers each with a different level of system access and privilege. Each of these categories of user can have specific users or groups of users subscribed to them, granting access to that specific level of privilege.46 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • It is also possible to limit the scope of the search for a user through Active Directory by limiting the search path to one group of users. Authentication against a Radius server. Similar to the Active Directory authentication is the Radius authentication. In this case it is also possible to assign groups to Tivoli Provisioning Manager for OS Deployment roles; however, it is not possible to limit the directory search path to a specific user group. Authentication against the local account database on the host server. This is similar to the domain authentication, however authentication and group membership is that of the local server account database. Use of the superuser account. Of course the simplest method of using the tool is to just have one user account and password. This of course would be a security breach in most organizations. A detailed description of how you go about setting up a Tivoli Provisioning Manager for OS Deployment authentication domain is in 7.6.1, “Creating the authentication domain” on page 353.2.2.2 Small site architecture The target site for our small Tivoli Provisioning Manager for OS Deployment design has the following characteristics: It has 200 Windows workstations of various configurations of Windows 2000 and Windows XP spread across two floors of an office building on two IP subnets. LAN speed is 100Mbps. The workstations were acquired over a five year period and there were at last count 12 different hardware configurations with no Standard Operating Environment (SOE). The CIO studied the costs involved in supporting the disparate workstation fleet with no SOE and decided to refresh every workstation over the next year and deploy an SOE based on Microsoft Vista. The organization has 15 Windows servers that include Windows 2000, and Windows 2003. These servers are in a data room connected by a 1GB switch to the network backbone. Last year one of the organization’s application server disks failed. It took three days to get the server back up again. The backups were all current; however, there was no build process for the server. The technician who built the server had left the company. Because no one could find the build media for the OS or the application, in the end it took three frantic days to rebuild Chapter 2. Architecture and deployment scenarios 47
  • the server and bring it back on line. The CIO wants this procedure automated so that this situation never arises again. The topology of the site is laid out in Figure 2-7. Tivoli Provisioning Manager for OS deployment server DB High speed network backbone Other servers Workstations Figure 2-7 Small site topology The organization’s requirements for the solution are as follows: – The ability to automate the rebuild of current workstations. – The ability to automate the rollout of the new Microsoft Vista SOE. – The ability to rebuild new workstations with the new SOE. – The ability to easily manage the different versions of their SOE. – The ability to use Tivoli Provisioning Manager for OS Deployment as a component of their disaster recovery plan for individual servers in their server fleet. – The system should pay for itself in savings made in man hours spent deploying and redeploying workstations and server infrastructure. The organization chose Tivoli Provisioning Manager for OS Deployment as the tool to help them fulfill their requirements. The following is a description of how they set up their environment to exploit the tool to their best advantage.48 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • The designThe requirements as stated above can easily be fulfilled by a single TivoliProvisioning Manager for OS Deployment server located within the server farmin the data room. This server would, like the rest of the server fleet, be aWindows server.Server hardwareA separate server was decided upon as the existing servers are currently allfairly heavily utilized. The specification of this server is appears in Table 2-3.Table 2-3 Small site server specification Quantity Server type Speed RAM Free Disk 1 Dual Xeon 1Ghz 1GB 10GbThis is the minimum specification for a Tivoli Provisioning Manager for OSDeployment server as documented in Tivoli Provisioning Manager for OperatingSystem Deployment Guide (Fix Pack 1), SC32-2582.The implementation of the Tivoli Provisioning Manager for OS Deploymentserver is described in Chapter 3, “Installing the Tivoli Provisioning Manager forOS Deployment environment” on page 75.As there is going to be one PXE server and several subnets, it is important to setup DHCP with options 43 and 60 enabled and configured so that theworkstations will know the IP address of the PXE server. A detailed explanationof these settings are in 3.4, “Advanced DHCP options” on page 115.ProfilesDue to the fact that the CIO wants to see a quick return on his investment with analmost immediate reduction in the cost of rebuilding workstations, it is decidedthat the following approach to build profiles will be taken.Unattended setup profilesThe current workstation fleet consists of a variety of hardware, and only adhocrebuilds are currently being executed. So the decision is made to quicklyimplement an unattended set up of Windows 2000 and Windows XP that catersto the variety of hardware currently used by the organization. It takes the ITdepartment just one day to assemble all of the drivers necessary to build thecurrent Windows 2000 workstation and a Windows XP workstation. Thisunattended setup is ready for use in one day.The same process is used for the assembly of the server build. Chapter 2. Architecture and deployment scenarios 49
  • The steps in this process are detailed in 4.4, “Creating an unattended profile for Windows 2000” on page 171. Clone profile The move to Microsoft Vista is a longer term project. The IT department is developing a SOE that has the same base for all users plus certain applications for specific job roles. They studied the capabilities of Tivoli Provisioning Manager for OS Deployment closely and decided to deploy these common applications as a part of the base image and other optional applications where possible as part of the deployment. The step-by-step process for the creation of a Vista clone profile can be found in Chapter 5, “Installing Vista systems” on page 213. The process used to bind software packages to a deployment scheme implicitly through rules or explicitly can be found in 7.2.1, “Binding software packages to deployment schemes” on page 319. Software All software currently in the production SOE needs to be packaged so that when the rebuild of a current workstation takes place packages can be reloaded as part of that process. A number of packages are built for applications and customizations required by the SOE. These packages are bound to the deployment scheme as per the example in “Binding software packages to deployment schemes” on page 319. Deployment schemes A number of deployment schemes are to be set up to meet the following conditions: The rollout of new computer hardware with the Vista SOE installed The rebuild of a single computers Multicast rollout deployment scheme This scheme is used for new hardware deployments where groups of workstations are built together. The characteristics of this deployment scheme are detailed in Table 2-4. Table 2-4 Multicast rollout deployment scheme Settings Setting Comment General settings Allow BOM editing Never (Always run Not necessary, all host unattended) information to be pre loaded50 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Settings Setting CommentRequest User confirmation No No allowance of user rejection of buildEnforce Model locking No Using a universal profileDeployment method Full Deployment Run sysprep at build timeWhen deployment is done Show green screen For visual confirmation of completionUnbind configuration at the Yes Another configuration willend be bound laterDeployment status report Store full log ---------------------------------Save deployment log to: --------------------------------- ---------------------------------Hardware inventory PCI, Disk, DMI Store hardware but no softwarePerform Inventory Locked ---------------------------------Network settingsBefore start wait 120 seconds To synchronize other multicast clientsBandwidth limitation 50Mbps Deployment will be across a production network, potentially during the dayDeploy using unicast No Using MulticastCrypt network traffic No Within a private networkUse “BIOS fall back MBR” No Not necessary. Tested theto start PXE adapter in this computer modelAlternate image server --------------------------------- This build is to come from the designated server and no otherRedeploymentRedeployment partition --------------------------------- ---------------------------------User authentication --------------------------------- ---------------------------------Authentication options --------------------------------- ---------------------------------Software binding settings Chapter 2. Architecture and deployment scenarios 51
  • Settings Setting Comment Discard all other binding No Apply group and hardware rules binding Bound software --------------------------------- --------------------------------- Single computer deployment scheme This scheme is for general use in one-off deployments or system rebuilds. The deployment occurs over a production 100Mbps LAN, probably during business hours. The characteristics of this scheme are laid out in Table 2-5. Table 2-5 Single computer deployment scheme Settings Setting Comment General settings Allow BOM editing Only for unknown new host Unnecessary for rebuilds but possibly necessary for a new computer Request User confirmation Yes Allow a user to reject a rebuild Enforce Model locking No Using a universal profile Deployment method Full Deployment Run sysprep at build time When deployment is done Reboot the computer Ready for use Unbind configuration at the No This configuration end Deployment status report Store full log --------------------------------- Save deployment log to: --------------------------------- --------------------------------- Hardware inventory PCI, Disk, DMI store hardware but no software Perform Inventory Locked Network settings Before start wait --------------------------------- Not using Multicast Bandwidth limitation 50Mbps 50% of the 100Mbps production bandwidth Deploy using unicast Yes ---------------------------------52 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Settings Setting Comment Crypt network traffic No Within a private network Use “BIOS fall back MBR” No Not necessary. Tested the to start PXE adapter in this computer model Alternate image server --------------------------------- There is no other local build server Redeployment Redeployment partition --------------------------------- --------------------------------- User authentication --------------------------------- --------------------------------- Authentication options --------------------------------- --------------------------------- Software binding settings Discard all other binding No Apply group and hardware rules binding Bound software --------------------------------- ---------------------------------Computer boot sequenceThere will be a variety of computer boot sequences for the different computers inthe organization’s environment. These are detailed below including thereasoning behind each one.ServersOnce built, servers will have their boot sequence changed to the following:1. Hard Disk2. CD ROM3. Removable device4. Network BootTo ensure that an inadvertent network boot does not start a deployment, the bootsetting for the server group is set to boot from hard drive. For a deployment tooccur this must be explicitly overridden.WorkstationsUser workstations will be set to boot in the following order:1. Hard Disk Chapter 2. Architecture and deployment scenarios 53
  • 2. CD ROM 3. Removable device 4. Network Boot These workstations will also have the RbAgent loaded. This will allow an administrator, in a situation where a workstation needs to be rebuilt, to shutdown and restart the computer off the network without needing to ask the user to change the boot order. Migration strategy Due to the small size of the organization, new profile and deployment schemes are not developed on the production server, but on dedicated workstations. Although not the ideal separate development environment that is best practice, this situation is the reality of many organizations that cannot justify the expenditure in the extra infrastructure necessary to build a dedicated test environment. So in this instance there is no migration as profiles are built on the production server. Security settings The organization runs an Active Directory for all its user authentication. It is decided that all users logging on to Tivoli Provisioning Manager for OS Deployment should also authenticate against Active Directory. Four user categories are defined within the system, and they are laid out in: Table 2-6. The roles range from Administrative access down to the sort of very restricted access that is given to contracted staff during a rollout.Table 2-6 Security roles Role Active HTTP console Security policy directory access group Administrator Administrators Access all areas No restriction Developer Developers OS Deployment - yes Deny changes to the server configuration Server Log files - yes Server parameters No Server status - Yes Operator Operators OS Deployment - yes Deny addition/removal of hosts Server Log files - No Deny any changes to RAD hosts Server parameters No Deny changes to the server configuration Server status - Yes54 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Role Active HTTP console Security policy directory access groupInstaller Installers OS Deployment - yes Deny addition/removal of hosts Server Log files - No Deny any changes to RAD hosts Server parameters No Deny changes to RAD deployment schemes Server status - No Deny changes to RAD software packages Deny changes to RAD system profiles Deny changes to the server configuration2.2.3 Enterprise architecture The target organization for our enterprise design is a growing organization based in London with branches in Wales, Scotland, England, and Northern Ireland. Each branch office has between 50 and 100 workstations and 4-10 servers. The organization wants the implementation to be global in nature, for example a central database for the deployment history and inventory. A central database also provides backup server capability. As is IT best practice, the organization wants the design to include a test facility for the creation and testing of profiles and packages. The test facility will include a development environment and a pre production environment. This environment will allow for the capture and testing of profiles, deployment schemes, and the export import process between environments. Following are the high-level requirements of the system: To develop a low-risk methodology of rolling out the new Vista SOE To reduce the cost and complexity of rebuilding a workstation To reduce the cost and complexity of rebuilding a server To make the rebuild process no touch To integrate the new tool into the existing corporate environment, tools and processes The design The requirements, stated in the previous section, can be fulfilled with Tivoli Provisioning Manager for OS Deployment server and a design that encompasses existing tools and processes within the organization. Chapter 2. Architecture and deployment scenarios 55
  • Test facility The test facility is being installed as two separate systems. First the development environment, then the pre production environment. Both of these environments are linked by a physical network and processes to migrate profiles from test to pre production. Figure 2-8 shows the topology of the test environment. Test facility Development environment Pre-production environment RAD archive transfer Same as production environment One standalone server + workstations – To a lower scale – On which new profiles, packages, … are created • 1 regional server only – One workstation of each type – Allows to test – Allows to test • Server replication • Tivoli Provisioning Manager for OS Deployment objects creation • Tivoli Provisioning Manager for OS Deployment archive importation • Tivoli Provisioning Manager for OS Deployment objects deployment • Deployment of RAD objects • Tivoli Provisioning Manager for OS Deployment • Backup mechanism in case of slave failure archive exportation Figure 2-8 Test facility Development environment This is a single server multi workstation environment. Development server hardware Table 2-7 shows you the development server hardware for the test facility. Table 2-7 Development server hardware Quantity Server type Speed RAM Free disk 1 Dual Xeon 1Ghz 1GB 10Gb56 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Note: Tivoli Provisioning Manager for OS Deployment will work on a server of a lower specification; however, the performance of the system may be compromised. During the course of writing this IBM Redbooks publication, we ran a Tivoli Provisioning Manager for OS Deployment server on a variety of hardware including a single CPU, 512MB VMware workstation.Development client hardwareClient hardware would ideally consist of one of every type of production clientsystem being used in the organization. This includes desktop workstations,laptops, servers, and virtual systems.Development installationInstallation of the Development Tivoli Provisioning Manager for OS Deploymentserver is simple as it uses the standard database, so it is just a matter offollowing the installation wizard.Pre-production environmentThe pre-production environment is a representative subset of the productionenvironment. It consists of a master server, a slave server, and where possibleone of each production target systems.Depending on the actual production topology it may be prudent to incorporate asimulated or real slow network link between the master and slave servers.For the purposes of this exercise we have drawn the pre-production environmentwith no reference to other systems. In reality the pre-production environmentmay be built within an existing pre-production environment representing a branchor department of an organization. This can be an important factor as the systemswill be co-existing in the production environment and sharing resources such asserver hardware and network bandwidth. It is important to understand how thereplication of images between servers will affect ongoing transactions andbackups.Pre-production server hardwareTable 2-8 shows you the pre-production server hardware for the test facility.Table 2-8 Pre-production server hardware Quantity Server type Speed RAM Free disk 2 Dual Xeon 1Ghz 1GB 10Gb Chapter 2. Architecture and deployment scenarios 57
  • Pre-production client hardware Client hardware would ideally consist of one of every type of production client system being used in the organization. This would include desktop workstations, laptops, servers, and virtual systems. Pre-production installation The pre-production environment’s installation is a little different from the development environment in that it utilizes a multi-user relational database management system. The full explanation of the installation of Tivoli Provisioning Manager for OS Deployment with an alternate database is included in 3.1.2, “Using alternate Relational Database Management Systems” on page 80”. The most important thing to remember when installing with the alternate database is that the database and an ODBC source (system DSN named AutoDeploy) must be installed before the Tivoli Provisioning Manager for OS Deployment wizard is run. After both the servers are installed, a replication regime needs to be set up to replicate deployment profiles that are imported from the development server to the pre production master server so that the profiles are available on the slave server for deployment and testing. To be an accurate reflection of a production environment, this replication regime should be the same as that in the production environment. A discussion regarding the different replication methods is included in “Image replication” on page 33”. Production environment The production environment, as represented in Figure 2-9 on page 59, shows the five sites sharing the one RDBMS with the London site acting as the master. The London server hosts the RDBMS for the implementation and is a dedicated server. The four slave servers are all being run on the local file and print servers at their respective sites.58 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Production server infrastructure The main Tivoli Provisioning Manager for OS Deployment server in London (M) M DB W S E NI One Tivoli Provisioning Manager for OS Deployment server Per region •Synchronized with the main Tivoli Provisioning Manager for OS Deployment •Utilizing the same database •Using the main Tivoli Provisioning Manager for OS Deployment in London as a backup server Workstations connected to the regional Tivoli Provisioning Manager for OS Deployment serverFigure 2-9 Production environmentThe server specifications are in Table 2-9.Table 2-9 Server specifications Servers Applications Server Speed RAM Free disk run type London Tivoli Dual 1GHZ 2GB 100GB Master OProvisioning Xean Manager for OS Deployment DB2® Branch File and Print Dual 1GHZ 1.5 GB 60GB Servers - slave services Xeon Dedicated diskThe master server is running 1GB of RAM for the Tivoli Provisioning Manager forOS Deployment server and 1GB for the DB2 server. As this will be a smalldatabase by any standard and there will be minimal querying, it is not necessary Chapter 2. Architecture and deployment scenarios 59
  • to increase the number of CPUs or to separate the DB2 off onto a separate server. 100GB of disk gives plenty of space for a large portfolio of images. The branch file and print servers were all running 512K of RAM. This was upgraded to 1.5GB when the Tivoli Provisioning Manager for OS Deployment was deployed along with a 60GB dedicated disk for images. Profiles The organization has approximately 400 workstations and 30 servers, and as such there are a variety of profiles that need to be made available to build and rebuild these computers. The function of the current builds are as follows: Transaction workstations. These are currently Windows XP and are primarily used to run the organization’s main transactional application, which is accessed via a Web browser. These users have access to an e-mail application and a number of other utility applications. They store no data on these computers and are allowed to make no changes to the look and feel of the operating environment. This control is exerted by security policy through Active Directory. The individual computers are not assigned to any one user. The employees who use the computers have no sense of ownership of them. Back office workstations. These workstations are currently also Windows XP but running many applications via a Web browser and loaded locally. These users do exercise a degree of autonomy over the look and feel of their computer as it is assigned to them and they use it exclusively. Within the various back office departments there are a variety of different applications loaded for different job roles. Although company policy is not to store data on the local computer hard drive, users do tend to have a lot of data stored locally. Power user workstations. These workstations are predominantly in the IT department, but there are a number scattered around the company via the informal network of friends. These are workstations based no the back office workstation but with fewer controls on configuration changes, usually with more memory, applications, and disk. Windows 2000 servers. The file and print services are all built on a Windows 2000 platform. It is a standard build but across a variety of models of server hardware60 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Windows 2003 servers. The e-mail system, accounting application, and a number of back end IT systems, such as backup, run on a Windows 2003 platform. This platform is also across a variety of Hardware models. Linux business application servers. There are 10 X86 multi CPU Linux servers running the organization’s business application. Each site has two load balanced servers linked back to the master site in London. A Windows Vista™ SOE is in development for the various workstation categories previously mentioned.Unattended setup profilesIt is decided that for all server builds, that is the Windows 2000, Windows 2003,and Linux server builds, that an unattended setup profile will be developed. Thisis because the predominant reason that one of the existing servers would berebuilt would be as part of a disaster recovery, that being a machine or a sitefailure. If that were to happen, the chances that the hardware the organizationwould be able to use for the replacement server would not necessarily be thesame or even come from the same vendor as the original server. Therefore itwas thought that the unattended setup offered more flexibility in this instance.Clone profileA universal image is developed for all SOE versions. Across the 400 workstationcomputers, there are only 15 different models, so it is easy to build the necessarydriver packages for injection into the image during the build process. The imageis based upon the transaction workstation used by operators for face-to-face andphone-based transactions.A naming convention within the organization designates a workstation’s functionand also the group that it is assigned to within Tivoli Provisioning Manager for OSDeployment. Each group has a profile bound to it so that when the workstation isbuilt or rebuilt it automatically gets the correct profile.The driver packages are bound to the PCI ID of the component it supports andso are automatically installed with an image if the computer hardware requiresthe driver.The base software required by all users has been included in the universalprofile.Deployment schemesA number of deployment schemes are to be set up to meet the followingconditions: Chapter 2. Architecture and deployment scenarios 61
  • The bulk rollout of new computer hardware with the Vista SOE installed The rebuild of a single computer The build of a single computer The build of a redeployable computer. This equates to three deployment schemes. Details of those three schemes follow. Multicast rollout deployment scheme This scheme will be used for new hardware deployments on a dedicated build LAN where groups of 10-15 workstations will be built at once. The characteristics of this deployment scheme are detailed in Table 2-10. Table 2-10 Multicast rollout deployment scheme Settings Setting Comment General settings Allow BOM editing Never (Always run Not necessary, all host unattended) information to be pre loaded Request User confirmation No No allowance of user rejection of build Enforce Model locking No Using a universal profile Deployment method Full Deployment Run sysprep at build time When deployment is done Show green screen For visual confirmation of completion Unbind configuration at the Yes Another configuration will end be bound later Deployment status report Store full log ---------------------------------- Save deployment log to: ---------------------------------- ---------------------------------- Hardware inventory PCI, Disk, DMI Store hardware but no software Perform Inventory Locked ---------------------------------- Network settings Before start wait 120 seconds To synchronize other multicast clients62 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Settings Setting Comment Bandwidth limitation None Dedicated build network Deploy using unicast No Using Multicast Crypt network traffic No Within a private network Use “BIOS fall back MBR“ No Not necessary, tested the to start PXE adapter in this computer model Alternate image server ---------------------------------- This build is to come from the designated server and no other Redeployment Redeployment partition ---------------------------------- ---------------------------------- User authentication ---------------------------------- ---------------------------------- Authentication options ---------------------------------- ---------------------------------- Software binding settings Discard all other binding No Apply group and hardware rules binding Bound software ---------------------------------- ----------------------------------Single computer deployment schemeThis scheme is for general use in one-off deployments or system rebuilds. Thedeployment will occur over a production 100Mbps LAN probably during businesshours. The characteristics of this scheme are in Table 2-11.Table 2-11 Single computer deployment scheme Settings Setting Comment General settings Allow BOM editing Only for unknown new host Unnecessary for rebuilds but possibly necessary for a new computer Request User confirmation Yes Allow a user to reject a rebuild Enforce Model locking No Using a universal profile Deployment method Full deployment Run sysprep at build time Chapter 2. Architecture and deployment scenarios 63
  • Settings Setting Comment When deployment is done Reboot the computer Ready for use Unbind configuration at the No This configuration end Deployment status report Store full log ---------------------------------- Save deployment log to: ---------------------------------- ---------------------------------- Hardware inventory PCI, Disk, DMI Store hardware but no software Perform Inventory Locked ---------------------------------- Network settings Before start wait ---------------------------------- Not using Multicast Bandwidth limitation 50Mbps 50% of the 100Mbps production bandwidth Deploy using unicast Yes ---------------------------------- Crypt network traffic No Within a private network Use “BIOS fall back MBR“ No Not necessary. Tested the to start PXE adapter in this computer model Alternate image server ---------------------------------- There is not other local build server Redeployment Redeployment partition ---------------------------------- ---------------------------------- User authentication ---------------------------------- ---------------------------------- Authentication options ---------------------------------- ---------------------------------- Software binding settings Discard all other binding No Apply group and hardware rules binding Bound software ---------------------------------- ---------------------------------- Redeployment deployment scheme Due to the utility nature of the transaction workstations, these workstations will be deployed with a redeployment scheme. The workstations will have a customized menu with the following two options:64 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 1. Quick Restore - this option will have a five second timer.2. Full format and restore.This will ensure that every time the PC is rebooted it is returned to its pristinestate reducing the need to log calls to the help desk for computer configurationissues.A screen shot of the menu is provided in Figure 2-10.Figure 2-10 Customized redeployment menuThe deployment scheme settings are laid out in Table 2-12.Table 2-12 Redeployment deployment scheme Settings Setting Comment General settings Allow BOM editing Only for unknown new host Unnecessary for rebuilds but possibly necessary for a new computer Chapter 2. Architecture and deployment scenarios 65
  • Settings Setting Comment Request User confirmation No No allowance for a user to reject a rebuild Enforce Model locking No Using a universal profile Deployment method Full Deployment Run sysprep at build time When deployment is done Reboot the computer Ready for use Unbind configuration at the No This configuration and end deployment scheme are to be bound to this computer Deployment status report Store full log ---------------------------------- Save deployment log to: ---------------------------------- ---------------------------------- Hardware inventory PCI, Disk, DMI Store hardware but no software Perform Inventory Locked ---------------------------------- Network settings Before start wait ---------------------------------- Not using Multicast Bandwidth limitation 50Mbps 50% of the 100Mbps production bandwidth Deploy using unicast Yes ---------------------------------- Crypt network traffic No Within a private network Use “BIOS fall back MBR“ No Not necessary, tested the to start PXE adapter in this computer model Alternate image server ---------------------------------- There is not other local build server Redeployment Redeployment partition 2000 Mb The size of the SOE User authentication Does not require ---------------------------------- authentication Authentication options ---------------------------------- ---------------------------------- Software binding settings66 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Settings Setting Comment Discard all other binding No Apply group and hardware rules binding Bound software ---------------------------------- ----------------------------------Computer boot sequenceThere will be a variety of computer boot sequences for the different computers inthe organization’s environment. These are detailed in the following sections,including the reasoning behind each one.ServersAfter built, servers will have their boot sequence changed to the following:1. Hard Disk2. CD ROM3. Removable device4. Network BootTo ensure that an inadvertent network boot does not start, a deployment bootsetting for the server group is set to boot from hard drive. For a deployment tooccur this must be explicitly overridden.Transaction workstationsThe Transaction workstations that will have a redeployment image stored locallywill be permanently set to boot in the following order:1. Network2. CD ROM3. Removable device4. Hard diskBooting off the network or the hard drive looks the same on a redeployablecomputer. There are two extra screens: the Tivoli splash screen and theRedeployment menu. However when booted off the network those screens aresourced from the Tivoli Provisioning Manager for OS Deployment server andtherefore can be changed by the administrator, adding or removing items withoutit being necessary to visit each computer. It is also possible to send a new imageto the computer without any physical contact to it. Chapter 2. Architecture and deployment scenarios 67
  • Back office and power user workstations The back office and power user workstations will be set to boot in the following order: 1. Hard disk 2. CD ROM 3. Removable device 4. Network boot These workstations will also have the RbAgent loaded. This will allow an administrator, in a situation where a workstation needs to be rebuilt, to shutdown and restart the computer off the network without needing to ask the user to change the boot order. Profile migration Profiles will be developed in the Test environment and initially tested there. After a profile is ready for production migration, it will be migrated from Test to pre production via a DVD. This process is explained in detail in ““Migration strategy” on page 54”. After the profile is tested in the pre production environment, the same DVD that was imported to pre production can be imported into the production environment. Using the same DVD ensures the integrity of the profile. Image replication Image replication between the different sites is going to be executed using the current replication tool in production within the organization. It was decided to use the current tool for a number of reasons: 1. Replication really only needs to occur on an ad-hoc basis; therefore, having another scheduled task on the network was an unnecessary management overhead. 2. Control. The organization has run on minimal network bandwidth between sites for many years. A focus on the traffic flowing over these network links made any upgrades unnecessary. By using the current replication tool, control over the traffic can be maintained. 3. The ability to stop and restart a replication, checkpoint restart capability, and adaptive bandwidth control are not part of the built-in replication service. Security settings The organization’s central authentication service is Microsoft Active Directory. It is decided that this will also be used for authentication in the Tivoli Provisioning Manager for OS Deployment solution.68 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Four user groups are created within Active Directory, one for each Tivoli Provisioning Manager for OS Deployment role. In the HTTP Console Security screen, the Active Directory groups are defined within each Tivoli Provisioning Manager for OS Deployment role. Then when users are subscribed to the Active Directory groups according to their designated role, they inherit access to the Tivoli Provisioning Manager for OS Deployment role. The four roles defined within the organization’s system are laid out in: Table 2-13.Table 2-13 Security roles Role Active HTTP console Security policy directory access group Administrator Administrators Access all areas No restriction Developer Developers OS Deployment - yes Deny changes to the server configuration Server Log files - yes Server parameters No Server status - Yes Operator Operators OS Deployment - yes Deny addition/removal of hosts Server Log files - No Deny any changes to RAD hosts Server parameters No Deny changes to the server configuration Server status - Yes Installer Installers OS Deployment - yes Deny addition/removal of hosts Server Log files - No Deny any changes to RAD hosts Server parameters No Deny changes to RAD deployment schemes Server status - No Deny changes to RAD software packages Deny changes to RAD system profiles Deny changes to the server configuration The company expands As is the way of the world our organization merges with another multinational organization. It is decided to expand the Tivoli Provisioning Manager for OS Deployment system. The new organization is spread around the world with offices in France, Spain, Austria, Germany, Japan, India, and Taiwan. The head office is still based in London. The existing architecture needs to be changed to more effectively deal with the larger organization. Architecture The new architecture will incorporate three tiers and break the organization up into the following three regions: Great Britain Europe Chapter 2. Architecture and deployment scenarios 69
  • Asia London will remain the master site. There will be four separate databases: a master in London and one each in the English, European, and Asian hub sites. There will be no replication of host information between these databases, only profile and deployment scheme data. The physical layout is shown in Figure 2-11. Adapting the production environment • Level 1 server has an independent database – Specific replication mechanism between level 1 and 2 servers Level • Level 2 and 3 servers share databases London • Level 2 are backup for level 3 servers 1 Great-Britain Europe Asia 2 3 Figure 2-11 Expanded production environment Profile development will continue to be done at the London master site. It is at this point that profiles are introduced to the system for replication out to the regions. Replication As with the original architecture, the actual replication of data is done using a third-party replication tool. The third-party tool allows the organization to manage the replication requirements of Tivoli Provisioning Manager for OS Deployment along with the rest of their data replication with one tool. In a large and complex environment such as this, being able to stop and start replication, dynamically70 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • adjust bandwidth utilization to the level of traffic on the network, and scheduledata movement adds real value.The process to drive replication from the command line is described in “Imagereplication” on page 33.Test environmentJust as the architecture of the production environment has changed with theexpansion of the organization, the test facility must change as well. There is littlepoint to having a pre-production environment if it does not mirror production in atleast the major functions. In the case of the test facility, to mirror production weneed to add another level of server to replicate the master site. The server thatwas the master server will now replicate that of a regional center. The newmaster server will have its own database that will not contain any hostinformation. This information is kept down at the regional level. This architectureis shown in Figure 2-12. Adapting the test facility • Development server remains identical • Pre-production server adds one level of servers RAD archive transferFigure 2-12 Expanding the test facility Chapter 2. Architecture and deployment scenarios 71
  • 72 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Part 2Part 2 Deployment In part two we discuss deployment scenarios with Tivoli Provisioning Manager for OS Deployment. This part also includes actual deployment steps.© Copyright IBM Corp. 2007. All rights reserved. 73
  • 74 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 3 Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment This chapter provides information about prerequisites for the installation as well as the installation procedure for Tivoli Provisioning Manager for OS Deployment server on Windows and Linux platforms. It also gives an overview of Web interface extension. Following is a list of topics: “Server installation on Windows systems” on page 76 “Installing the server on Linux systems” on page 91 “Initial login and installation verification” on page 112 “Advanced DHCP options” on page 115 “Web interface extension” on page 123© Copyright IBM Corp. 2007. All rights reserved. 75
  • 3.1 Server installation on Windows systems This chapter gives you a step-by-step guide to the product installation on Windows. Installation was done on Windows 2003 but should be the same for all supported Windows platforms.3.1.1 Prerequisites In this chapter we list hardware and software prerequisites for installation of Tivoli Provisioning Manager for OS Deployment server on Windows. These prerequisites are for product version 5.1.0.1. Please consult product documentation for a complete list of prerequisites. You can find the latest documentation of all Tivoli products at the following Web site: http://publib.boulder.ibm.com/tividd/td/tdprodlist.html Hardware prerequisites Table 3-1 lists the minimum requirements for Tivoli Provisioning Manager for OS Deployment server installation. Table 3-1 Tivoli Provisioning Manager for OS Deployment server system requirements Server type Processor speed RAM Free disk space Dual-Xeon 1 GHz CPU Minimum 1 GB Minimum 10 GB Table 3-2 contains the configuration information of the machine used in our lab as the Tivoli Provisioning Manager for OS Deployment Windows server. Table 3-2 Lab Windows server configuration Server type Processor speed RAM Free disk space Intel® Pentium® 4 3.0 GHz 1.5 GHz 80 GB Software prerequisites Tivoli Provisioning Manager for OS Deployment server on Windows platform has to be installed on one of the following Windows versions: Windows 2000 Server Windows 2003 Server Tivoli Provisioning Manager for OS Deployment requires a functional DHCP server in the environment. Database for storing information about hosts, deployment states, and other data required by the server is also required.76 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • DHCP prerequisites For Tivoli Provisioning Manager for OS Deployment to operate properly a functional DHCP server is required. If options 43 or 60 are set, remove them. If you do not know what options 43 and 60 are or how to set them, please check 3.4, “Advanced DHCP options” on page 115. There are two possible scenarios: Tivoli Provisioning Manager for OS Deployment server and DHCP server reside on different machines. Tivoli Provisioning Manager for OS Deployment server and DHCP server reside on the same machine. In the first case where two different machines are used, you do not have to configure anything on DHCP server. Tivoli Provisioning Manager for OS Deployment server listens to DHCP requests sent by PXE clients and offers PXE parameters without disturbing normal DHCP operation. Important: If your Tivoli Provisioning Manager for OS Deployment server and DHCP server reside on the same machine you must set DHCP option 60 (class identifier) to PXEClient. In the second case, you need to specify option 60 to PXEClient on DHCP server to let clients know that Tivoli Provisioning Manager for OS Deployment server is on the same IP address as the DHCP server. Adding DHCP option 60 to Windows 2000/2003 DHCP server By default, option 60 is not set on Windows 2000/2003. If the Tivoli Provisioning Manager for OS Deployment server is running on the same host as the DHCP server, you have to add this option and set its value to PXEClient in order to tell PXE clients that both servers are on the same machine. Use the following steps to add option 60 on Windows 2000: 1. Open a command window (select Start → Run → cmd). 2. Type netsh. 3. Type dhcp. 4. Type server servername or server ip_address. You should then see a command prompt that says: dhcp server>. 5. Type add optiondef 60 PXEClient STRING 0 comment=”Enable PXE boot”. 6. Type set optionvalue 60 STRING PXEClient. 7. To confirm that everything was set correctly, type show optionvalue 60.Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 77
  • Following is an example of setting up option 60 on Windows DHCP server in our environment. Command netsh was started locally on the DHCP server. Example 3-1 Setting DHCP option 60 in Windows C:>netsh netsh>dhcp netsh dhcp>server localhost netsh dhcp server>add optiondef 60 PXEClient STRING 0 comment="Enable PXE boot" Command completed successfully. netsh dhcp server>set optionvalue 60 STRING PXEClient Command completed successfully. netsh dhcp server>show optionvalue 60 DHCP Standard Option : General Option Values: OptionId : 60 Option Value: Number of Option Elements = 1 Option Element Type = STRING Option Element Value = PXEClient Command completed successfully. netsh dhcp server>exit Note: Due to the nature of PXE, you cannot run two PXE servers on the same machine at the same time. If you installed another PXE boot tool such as Microsoft ADS, you should disable it prior to installing Tivoli Provisioning Manager for OS Deployment. Adding DHCP option 60 to a host with ISC DHCP server If you are using the Internet Software Consortium (ISC) DHCP server 2.0, you can add the DHCP option 60 to a group of hosts or to a single host by adding the following statement to a section of the configuration file: option dhcp-class-identifier “PXEClient”; If you were using option 43 (vendor-encapsulated-options) for another PXE application, remove it for Tivoli Provisioning Manager for OS Deployment hosts.78 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • The modifications to perform on an ISC DHCP server 3.0 are the same as for a 2.0 server, but the names differ: For the hosts running Tivoli Provisioning Manager for OS Deployment you have to add the following statement: vendor-class-identifier “PXEClient”; If you are running any other PXE applications you have to remove any occurrences of the following statement: option space PXE; The Tivoli Provisioning Manager for OS Deployment server will respond to all requests, including requests originating from unknown hosts. If the option “Completely ignore unknown hosts” is set for the server, it will only respond to discovery requests originating from known hosts. You can specify either the IP address or the Ethernet address on the host list. At this stage the IP address of the remote-boot client is known. Tip: The VMWare DHCP server is actually ISC DHCP 2.0. This allows you to configure options 43 and 60 for your virtual machines without needing to install and configure DHCP additional servers inside one of the virtual machines. Database prerequisites When installed for the first time on Windows, Tivoli Provisioning Manager for OS Deployment can set up a Microsoft Access database that is used for storing all parameters and host inventory. You do not need MS Access to use it, the MDAC component of Windows 2000/XP/Vista (and freely available for other versions of Windows from the Microsoft Web site) is sufficient for Tivoli Provisioning Manager for OS Deployment to work. Although this database is sufficient for using Tivoli Provisioning Manager for OS Deployment with a few hundred clients, you might need to customize or convert the database for integration into a corporate environment. Tivoli Provisioning Manager for OS Deployment supports custom databases, and any ODBC compliant database engine such as DB2, Microsoft SQL Server, or Oracle®. If you want to use your own ODBC/JDBC™ source, ensure that it was created as a System DSN (not a User DSN) because it has to be usable by the Tivoli Provisioning Manager for OS Deployment Server service. Before starting the installation of Tivoli Provisioning Manager for OS Deployment server, create an empty database and a System DSN pointing to this database. Tivoli Provisioning Manager for OS Deployment server automatically populates the database with the necessary tables. You can find detailed instructions on how to create ODBC data source in “Creating the ODBC data source” on page 82.Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 79
  • Note: If you want to use a database other than Microsoft Access, create the database and ODBC data source before you start installing Tivoli Provisioning Manager for OS Deployment server. The ODBC data source has to be defined on the same machine where Tivoli Provisioning Manager for OS Deployment server will be installed.3.1.2 Using alternate Relational Database Management Systems In our lab we decided to test Tivoli Provisioning Manager for OS Deployment with DB2. This chapter describes how to configure DB2-based ODBC data source for use with Tivoli Provisioning Manager for OS Deployment. The instructions given here are for DB2 but should be similar for any other ODBC compliant database. Important: ODBC data source configuration is done on Tivoli Provisioning Manager for OS Deployment server. The data source has to be system data source, not user data source. Creating the DB2 database When creating the DB2 database, no special options are required. Also you are not required to create database tables in the database. These are created automatically the first time Tivoli Provisioning Manager for OS Deployment server connects to the database. All you have to do is create the database. Use the following steps to create a DB2 database: 1. Start a DB2 command line by selecting Start → Run → db2cmd. 2. Type db2 create db tpmosd. Figure 3-1 on page 81 shows the output.80 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 3-1 Creating DB2 database on Windows ODBC driver installation If your database resides on a remote DB2 server you must have an ODBC driver installed on the Tivoli Provisioning Manager for OS Deployment server to connect to that database. If your database is on the same machine as Tivoli Provisioning Manager for OS Deployment server, this driver was already installed when you installed DB2 Server. There are many ways to install the DB2 ODBC driver. This driver is shipped with DB2 Server, DB2 Administrative Client, and DB2 Run-time Client. If you do not have any of the mentioned components installed on the Tivoli Provisioning Manager for OS Deployment server machine you can download and install DB2 Run-time Client Lite. This package has less than 20 MB and you can get it from the following location: https://www6.software.ibm.com/dl/rtcl/rtcl-p Use your IBM user ID to log on to the page. If you do not have one you can freely register using the link on the same page. After you download the package, install DB2 Run-time Client “Lite” using Typical install.Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 81
  • Creating the ODBC data source Perform the following steps to create an ODBC data source: 1. To start ODBC Data Source Administrator choose: On Windows 2000: Start → Settings → Control Panel → Administrative Tools → Data Sources (ODBC) On Windows 2003: Start → Control Panel → Administrative Tools → Data Sources (ODBC) 2. After you start the ODBC Data Source Administration program, select the System DSN tab. You should see the following panel. If you included Microsoft Access database in the installation you will see the AutoDeploy data source already defined. You can see it is using Microsoft Access driver. See Figure 3-2. Figure 3-2 ODBC Data Source Administrator 3. If you have the AutoDeploy data source defined, delete it by selecting the data source, and then clicking the Remove button. Click Yes when asked for confirmation. 4. To create a new data source click the Add... button. You are presented with a screen that lists all of the ODBC drivers on the system. Find the IBM DB2 ODBC DRIVER item in the list, and select it. Click Finish as shown in Figure 3-3 on page 83.82 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 3-3 Select ODBC driver 5. After you select the correct ODBC driver, enter the parameters required to define an ODBC data source. First, enter the ODBC data source name. The ODBC data source name must be AutoDeploy (See Figure 3-4). If your database is on this machine you can select it from the Database alias pull-down menu. Figure 3-4 Selecting ODBC data source name and the database alias it points to 6. If your database is on the remote machine, add the database to this menu by clicking the Add button. Note that this button is disabled if the Data source name field is empty. After you click the Add button, you can define parameters for connection to your database. 7. Verify that the Data source name field is set to AutoDeploy. Click the TCP/IP tab, and type the required parameters. The database name and alias should match the name of the database you created. In the Host name field you can enter either the host name or the IP address of the database server. Finally, the port number has to correspond to the instance in which the database isChapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 83
  • created. The default for a single-instance database server is 60000. If unsure, contact your database administrator. See Figure 3-5. Figure 3-5 Connecting to remote DB2 database 8. Click the OK button to create the data source. You should see the AutoDeploy data source in the list of defined ODBC data sources, as shown in Figure 3-6. Figure 3-6 Defined AutoDeploy ODBC data source84 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 9. To verify this ODBC data source click the Configure... button, and enter credentials for connection to the database in the User ID and Password fields. Test the connection by clicking the Connect button. See Figure 3-7. Figure 3-7 Testing connection to ODBC data source 10.If you get the message “Connection tested successfully”, then your ODBC data source is properly defined. If you get an error message verify your connection settings.3.1.3 Installing the Tivoli Provisioning Manager for OS Deploymentserver Perform the following steps to install the Tivoli Provisioning Manager for OS Deployment server: 1. When you run the installation program, the very first screen of the installation requires you to choose the language of the installation. Some options use Asian fonts and will appear as boxes if you do not have proper fonts installed (See Figure 3-8 on page 86). If you do not intend to use one of the Asian languages for installation, you do not have to worry about this. Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 85
  • Figure 3-8 Choose language 2. After the welcome screen and product license you a screen appears that allows you to choose Tivoli Provisioning Manager for OS Deployment components (Figure 3-9 on page 87). By default all components are installed, and in typical installations you do not need to change these defaults. If for some reason you do want to change them, following is what they stand for: – OS Deployment server - Tivoli Provisioning Manager for OS Deployment core server installation files - if you deselect this one you will not install the server. – ODBC Gateway - this service allows Tivoli Provisioning Manager for OS Deployment clients to use an ODBC source to retrieve their configuration and to store inventory information in a database. This service is automatically started and stopped when the Tivoli Provisioning Manager for OS Deployment server service is started and stopped. – Access data file - in order to have an ODBC data source out-of-the-box, Tivoli Provisioning Manager for OS Deployment ships with a prebuilt Microsoft Access database. If you plan on using a different database you do not have to install this component. Take note that Tivoli Provisioning Manager for OS Deployment server will not function properly until you configure this other data source. – Multilingual interface - you can choose which languages will be available in the user interface by selecting/deselecting items under this option. – Web interface extension - this option allows you to use Web interface. If you do not install this option you will not be able to use Web interface for product administration and configuration.86 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 3-9 Choose components 3. The following screen allows you to specify the server data folder. This folder is used for storing images, Rembo Auto Deploy (RAD) export/import files, server and client log files, and other data required by the server. Make sure this location has sufficient space since client images can have several gigabytes of data. Figure 3-10 Select server data folder 4. We are using Web console to administer our server. To do so we need to configure ports on which our server will run. These ports must not be in useChapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 87
  • by other programs. The default ports are 8080 for HTTP (non-encrypted) communication and 443 for HTTPS (encrypted) communication. You must change these if they conflict with other open ports on the server. Checking the Disable HTTPS console access check box disables HTTPS access to the console, and you will be able to connect to the console using only HTTP. If you choose to use HTTPS, a self-signed certificate is automatically created. See Figure 3-11. Figure 3-11 Choose ports 5. The screen in Figure 3-12 on page 89 allows you to enter super-user’s username and password. This username and password is for initially logging onto the console. It is also used when setting up replication between servers. This user ID is intended to be used only by the main OS provisioning server administrator in order to get access to all configuration parameters of the server. There is only one super-user login. You can specify additional users and assign them different permissions using administrative console. Note: Super-user ID is not created on the operating system. Credentials for this user are only created and stored in the rembo.conf file. Web interface extension (also known as RbAgent) is a very useful part of Tivoli Provisioning Manager for OS Deployment. It allows the administrators to remotely access local drives, reboot machines in order to start the provisioning process, collect DMI scan information, and so on.88 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 3-12 Enter administrator’s credentials The credentials you enter on the screen in Figure 3-13 on page 90 are used to run the Web interface extension service. Make sure this account has enough privileges to access the folders and files you want to use with Tivoli Provisioning Manager for OS Deployment. It also has to have “Logon as a service” privilege. Tip: To assign “Log on as a Service” right to a user on Windows 2000/2003 server, click Control Panel → Administrative Tools → Local Security Policy → Local Policies → User Rights Assignments → Log on as a service. Since we were working in a lab environment and wanted to have full access to all drives and directories we used a local administrative account. For more information on this topic go to 3.5, “Web interface extension” on page 123.Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 89
  • Figure 3-13 Configure Web interface extension 6. If Tivoli Provisioning Manager for OS Deployment installation detects a system ODBC data source called “AutoDeploy”, it will present you with the following screen in Figure 3-14. The ODBC driver might be different depending on the Relational Database Management System (RDBMS) you use. Enter the required credentials to connect to the data source. Figure 3-14 ODBC data source credentials90 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 7. That is all the information required to install Tivoli Provisioning Manager for OS Deployment server. Click Next and then Install to complete the installation of the product.3.2 Installing the server on Linux systems This section describes the installation of Tivoli Provisioning Manager for OS Deployment on Linux operating systems. Although we refer to a specific release of the Tivoli Provisioning Manager for OS Deployment, 5.1.0.0, and to a specific distribution of Linux, the SuSE Linux Enterprise Server 9, the steps you perform are very similar among different releases of the product and different distributions of Linux. Starting from a standard installation of a Linux operating system, we present a complete sequence of instructions that will lead to a running Tivoli Provisioning Manager for OS Deployment environment using IBM DB2 as the RDBMS. Furthermore some tuning and configuration steps are performed in order to have the environment working at each boot of the machine. Tivoli Provisioning Manager for Operating System Deployment Guide (Fix Pack 1), SC32-2582 only describes the UNIX/Linux installation using a MySQL database. We walk you through the steps of installing the product to work with a DB2 database; moreover, we will provide some details to let advanced users tune and configure the Tivoli Provisioning Manager for Operating System Deployment. The following shows how to build a Tivoli Provisioning Manager for OS Deployment environment using the following five main steps: 1. Install the Relational Database Management System. 2. Install the Tivoli Provisioning Manager for OS Deployment server. 3. Configure the Tivoli Provisioning Manager for OS Deployment environment. 4. Run the Tivoli Provisioning Manager for OS Deployment environment. 5. Upgrade using fixpacks (optional). We start with discussing the prerequisites that the Tivoli Provisioning Manager for OS Deployment environment needs, then we go through each of the previously mentioned five steps. Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 91
  • 3.2.1 Prerequisites Planning the Tivoli Provisioning Manager for OS Deployment installation means checking if our environment meets the product requirements. We will overlook the client requirements since it is not the intent of this section; instead, we focus on the server component requirements. Software requirements As stated in Tivoli Provisioning Manager for Operating System Deployment Guide (Fix Pack 1), SC32-2582, the supported Linux platforms are the following: Fedora Core 3,4,5 (i386™) Red Hat Enterprise Linux: RHEL3, RHEL4 (i386) SuSE Linux Professional: 8,9,10 (i386) SuSE Linux Enterprise Server: SLES9 (i386) Debian GNU/Linux: Debian Sarge 3.1 (i386) We meet these requirements using the machine manchester.itsc.austin.ibm.com, equipped with a SuSE Linux Enterprise Server 9 whose kernel version is 2.6.5-7.97-smp. Tivoli Provisioning Manager for Operating System Deployment Guide (Fix Pack 1), SC32-2582 shows a supported RDBMS (for the UNIX/Linux installation) only, the MySQL database, explaining in detail how to use it with the product. Although not mentioned in the manual at the time of writing this IBM Redbooks publication, the IBM DB2 database is officially supported. We will use the latter, IBM DB2 Universal Database™ (UDB) Enterprise Server Edition (ESE) V8.1, because the Tivoli Provisioning Manager for OS Deployment server needs a reliable database to avoid inconsistency and data corruption. Another reason to use IBM DB2 is the possibility to have more synchronized Tivoli Provisioning Manager for OS Deployment servers distributed on different machines that can share the same database. This is the case where the advanced feature of the IBM DB2 can be configured to obtain better performance. Since the Tivoli Provisioning Manager for OS Deployment data are mostly stored on a file system, it could be useful to use a RAID system to prevent some common risks. On some Linux distributions, it can be performed by the operating system itself. The last prerequisite is a DHCP server, correctly configured to support the PXE-boot server provided by the Tivoli Provisioning Manager for OS Deployment server. It may happen that the DHCP server is installed on a different machine92 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • from the Tivoli Provisioning Manager for OS Deployment server or they may reside on the same machine; nonetheless, both the configurations are supported. Hardware requirements The hardware requirements for the machine where the Tivoli Provisioning Manager for OS Deployment will run are described in Table 3-3: Table 3-3 Tivoli Provisioning Manager for OS Deployment server hardware requirements Server Type Processor Speed RAM Free Disk space Dual-Xeon 1GHz CPU 1 GB 10 GB The manchester.itsc.austin.ibm.com machine that we use is an IBM xSeries® 342 provided with the following equipment: Table 3-4 Hardware used for the Tivoli Provisioning Manager for OS Deployment server Server Type Processor Speed RAM Free Disk space IBM xSeries 342 2 x 1GHz 2 GB 60 GB3.2.2 Installing the Relational Database Management System As previously mentioned we will install the IBM DB2 Relational Database Management System version 8.1. Access to the database is performed through a component of the Tivoli Provisioning Manager for OS Deployment server that is called Database gateway (DBGW). It was designed to interface the product to the deployment database managed by the Relational Database Management System. On UNIX/Linux systems, the DBGW is a Java™ archive (dbgw.jar) that connects the Tivoli Provisioning Manager for OS Deployment server to the Relational Database Management System using the JDBC connection. IBM DB2 supports four types of JDBC connections depending on the environment and the components installed. Since the IBM DB2 will be installed on the same machine where the Tivoli Provisioning Manager for OS Deployment will run, we describe the details of setting up a database connection only in this specific configuration. For further details on JDBC and DB2 connectivity, read the document at the following Web address: http://www-128.ibm.com/developerworks/db2/library/techarticle/0203zikop oulos/0203zikopoulos.html Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 93
  • Manually installing with the db2_install script We will start the IBM DB2 Universal Database (UDB) Enterprise Server Edition (ESE) V8.1 database installation using the db2_install script. For more details about the IBM DB2 product, refer to the IBM DB2 Information Center at the following Web location: http://publib.boulder.ibm.com/infocenter/db2luw/v8//index.jsp Usually the IBM DB2 installer for Linux systems is provided in a tar.gz format. Unpack it, and run db2_install command with -p option, indicating the acronym of the DB2 product to be installed: ./db2_install -p ese With this command, the IBM DB2 Universal Database (UDB) Enterprise Server Edition (ESE) V8.1 is installed on the default path /opt/IBM/db2/V8.1. We use the default configuration for kernel parameters, semaphore array, and message queue limits, as shown by the ipcs -l command. See Example 3-2. Example 3-2 ipcs -l command manchester:/opt/IBM/db2/V8.1 # ipcs -l ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 262144 max total shared memory (kbytes) = 8388608 min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 1024 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 1024 max size of message (bytes) = 8192 default max size of queue (bytes) = 16384 After the installation, manually set the DB2 server. Following is the procedure we will perform: 1. Create group and user IDs for a DB2 installation. 2. Create a DB2 Administration Server (DAS).94 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 3. Create an instance using db2icrt. 4. Create links for DB2 |files (Optional). 5. Configure TCP/IP communications for a DB2 instance. 6. Update the product license key. Creating the needed user and group accounts is performed on Linux with the groupadd and mkuser commands: Example 3-3 groupadd and mkuser commands groupadd -g 999 db2iadm1 groupadd -g 998 db2fadm1 groupadd -g 997 dasadm1 mkuser -u 1004 -g db2iadm1 -m -d /home/db2inst1 db2inst1 mkuser -u 1003 -g db2fadm1 -m -d /home/db2fenc1 db2fenc1 mkuser -u 1002 -g dasadm1 -m -d /home/dasusr1 dasusr1 Then, we create the DB2 Administration Server with the dascrt command: /opt/IBM/db2/V8.1/instance/dascrt -u dasusr1 The next step creates the DB2 instance with the db2icrt command: /opt/IBM/db2/V8.1/instance/db2icrt -a server -u db2fenc1 db2inst1 To run JDBC programs on UNIX/Linux systems with DB2 JDBC support, ensure that the DB2 parameter JDK_PATH is correctly set pointing to an existing JDK™ path. If you need to modify the DB2 configuration to set the correct JDK_PATH parameter, you should run the following commands after logging in as the instance owner: Example 3-4 Setting the correct JDK_PATH parameter db2 update dbm cfg using JDK_PATH /opt/IBMJava2-142 db2 update admin cfg using JDK_PATH /opt/IBMJava2-142 Since we will use the IBM DB2 Driver for JDBC and SQLJ type 4 connectivity, we only need to enable the DB2 TCP/IP listener. To do this, first we need to check that the file /etc/services contained in the port that will be used by the DB2 listener for the TCP/IP connections. In our case the TCP/IP listener DB2_db2inst1 will use the 60000 port: Example 3-5 /etc/services file manchester:/ # cat /etc/services | grep DB2 ibm-db2 523/tcp # IBM-DB2Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 95
  • ibm-db2 523/udp # IBM-DB2 questdb2-lnchr 5677/tcp # Quest Central DB2 Launchr questdb2-lnchr 5677/udp # Quest Central DB2 Launchr DB2_db2inst1 60000/tcp DB2_db2inst1_1 60001/tcp DB2_db2inst1_2 60002/tcp DB2_db2inst1_END 60003/tcp After logged as the instance owner (db2inst1 in our case), to activate the TCP/IP listener that will provide the needed JDBC connectivity we have to insert the port number in the DB2 server configuration and set the environment variable DB2COMM to TCP/IP. Example 3-6 Setting the environment variable DB2COMM db2set DB2COMM=TCPIP db2 update dbm cfg using SVCENAME 60000 You need to restart the DB2 server now: Example 3-7 Restart the DB2 server ./db2stop ./db2start The last step of the installation requires that you activate the license of the IBM DB2 product, as shown in Example 3-8: Example 3-8 Activate the license of the IBM DB2 product db2instance_path/adm/db2licm -a db2ese.lic DBI1402I License added successfully If you are logged as user db2inst1 you can start your db2 instance with the db2start command and create the deployment database that will be used by TPM for OS Deployment. From the DB2 CLP, we choose “tpmfosd” as the name for the deployment database: db2 => create database tpmfosd In 3.2.4, “Configuring the Tivoli Provisioning Manager for OS Deployment environment” on page 104, we describe how to configure the DB2 server to start at each boot of the machine in order to always have the Tivoli Provisioning Manager for OS Deployment environment up and running.96 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 3.2.3 Installing the Tivoli Provisioning Manager for OS Deploymentserver Now that we have the deployment database created (we called it tpmfosd) we will proceed by installing the Tivoli Provisioning Manager for OS Deployment server using the manual installation as described in Tivoli Provisioning Manager for Operating System Deployment Guide (Fix Pack 1), SC32-2582. The manual installation is needed because some customizations should be performed and some steps differ from the documented procedure. This is mainly due to the installation script provided in the current release of the product, which was built to work only with the MySQL database, even if the DBGW component can support the IBM DB2 JDBC connector. For this reason, we will follow the manual steps as described in the guide, except for the following: We use the IBM DB2 JDBC connector instead of the MySQL one. Instead of the MySQL “embedded” parameter provided by default, we will use IBM DB2 parameter for DBGW connection. Note: The setup script will be improved in the next release of Tivoli Provisioning Manager for OS Deployment to provide support to other databases during the installation. The steps to be performed can be summarized as follows: 1. Run the installer: a. Unpack the Tivoli Provisioning Manager for OS Deployment binaries. b. Create links to the IBM DB2 JDBC connector files. c. Run the setup script. 2. Customize the installation: a. Modify DBGW parameters in radb.ini file. b. Modify DBGW parameters in startup script. Running the installer The Tivoli Provisioning Manager for OS Deployment installer is provided in a .tar.gz format (TPMfOSd-5.1.000.32-linux.tar.gz). 1. Unpack the tar file some where in your file system. We do this in the /usr/local folder obtaining the directory tpmfos-5.1. See Example 3-9. Example 3-9 Unpack the installer manchester:/usr/local # gunzip TPMfOSd-5.1.000.32-linux.tar.gz manchester:/usr/local # tar -xvf TPMfOSd-5.1.000.32-linux.tar Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 97
  • manchester:/usr/local # cd tpmfos-5.1 manchester:/usr/local/tpmfos-5.1 # The folder tpmfos-5.1 will contain the following files: Example 3-10 tpmfos-5.1 folder contents . .. LICENSE-AGREEMENT dbgw.jar hostsync.nc netdebug radsync.nc rbcc rembo setup NOTICES docs netclnt packages rbagent rbnetfs.so scripts 2. Create the required links in the /usr/local/tpmfos-5.1 folder to the IBM DB2 JDBC connector files. These links will help during the start up of the DBGW, which needs those files in the CLASSPATH parameter. Since we are using the JDBC type 4, the required jar files to link are as follows: db2jcc.jar db2jcc_license_cu.jar The links can be created using the ln -s command as shown in Example 3-11: Example 3-11 ln -s command manchester:/usr/local/tpmfos-5.1 # ln -s /home/db2inst1/sqllib/java/db2jcc.jar db2jcc.jar manchester:/usr/local/tpmfos-5.1 # ln -s /home/db2inst1/sqllib/java/db2jcc_license_cu.jar db2jcc_license_cu.jar 3. Now we can run the setup script customizing the installation and configuring the connection for the IBM DB2 database. The IBM DB2 JDBC parameters are as follows:98 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • DB2 IP Address = 127.0.0.1 since the IBM DB2 server was installed on the manchester machine DB2 port = 60000 as defined previously DB2 database name = tpmfosd as defined previously DB2 credentials = db2inst1 as the instance owner Example 3-12 shows our installation steps: Example 3-12 Installation steps manchester:/usr/local/tpmfos-5.1 # ./setup 1) English 2) Español 3) Français 4) Deutsch 5) Italiano 6) Português 7) í•œêμ-ì–´ 8) 日本語 9) ç 体ä¸-æ–‡ 10) ç é«”ä¸-æ–‡ --> 1 IBM Tivoli Provisioning Manager for OS Deployment setup v.5.1 (000.32) Licensed Materials - Property of IBM. (C) Copyright IBM Corporation 1998, 2006. All Rights Reserved. IBM, the IBM logo, and Tivoli are trademarks of IBM Corporation in the United States, other countries or both. This program will configure and initialize the OS deployment server. Do you want to continue? [y/n (Default n)]: y Enter the installation directory [/usr/local/tpmfos-5.1]: /usr/local/tpmfos-5.1 This software requires a large amount of disk space to store client images. Please enter the directory where to store these data. Data directory [/usr/local/tpmfos-5.1/files]: /usr/local/tpmfos-5.1/files This software can be managed from a web-based console. You can choose to use a secure link (HTTPS) to the server console.Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 99
  • You can also change the default ports. You must also choose the administrator name Do you want to use SSL to access the Web interface? [y/n (default y)]: y Enter the HTTP console port [8080]: 8080 Enter the HTTPS console port [443]: 443 Enter the administrator name [admin]: admin Enter the administrator password: Confirm password: According to the RPM database, the Java package is not installed Do you want to install the Java package with YaST? [y/n (default y)]: n According to the RPM database, the MySQL Connector/J package is not installed Do you want to install MySQL Connector/J package with YaST? [y/n (default y)]: n According to the RPM database, MySQL server package is not installed Do you want to install MySQL server with YaST? [y/n (default y)]: n This software requires a third party database to store deployment objects. Can you provide a MySQL database? [y/n (default y)]: y Enter the IP address of your MySQL server [127.0.0.1]: 127.0.0.1 Enter the port used by your MySQL server on 127.0.0.1 [3306]: 60000 Enter the name of an existing (empty) database [AutoDeploy]: tpmfosd If the database tpmfosd on server 127.0.0.1 does not exist, please create it now! Press return to continue... Enter the user name to access the database [root]: db2inst1100 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Enter the password to access the database: Confirm password: The installation program will now create the configuration file and initialize the server. Please wait... IBM Tivoli Provisioning Manager for OS Deployment server v.5.1 (000.32) Licensed Materials - Property of IBM. L-DDAC-6RLW3E (C) Copyright IBM Corporation 1998, 2006. All Rights Reserved. IBM, the IBM logo, and Tivoli are trademarks of IBM Corporation in the United States, other countries or both. ** Rembo server has successfully stopped OS deployment server initialized successfully. File /usr/local/tpmfos-5.1/files/global/rad/radb.ini created successfully. URL to access database: mysql://127.0.0.1:60000/tpmfosd?useUnicode=true&characterEncoding=UTF-8 Username to access the database: db2inst1 Password to access the database: hidden Do you want to create startup scripts? [y/n (default y)]: y ... ... ... Startup scripts (rembo, dbgw, rbagent) have been created in /etc/rc.d/init.d. Do you want to start all the services ? [y/n (default y)]: n Goodbye!Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 101
  • Tip: Pay attention when prompted to install the MySQL database and the MySQL/J connector package. Obviously you should answer No. But, when the installer asks you the following: This software requires a third party database to store deployment objects. Can you provide a MySQL database? [y/n (default y)]: You must answer Yes, even if you will provide a DB2 database instead of the expected MySQL because replying No causes the installation to be cancelled. This is a well-know problem of the installer that is fixed in the next release. Then, you can continue the installation providing the IDB DB2 parameters even if the installer believes you are referring to a MySQL database. Since the MySQL connection is embedded in the installer all the database scripts created will have a wrong connection path. To fix this, a last configuration step is needed before running the system, so we answer as not to start the services at the end of the installation. Customizing the installation What we need to do is modify the connection string used by the DBGW component to interface with the database. 1. We edit the /usr/local/tpmfos-5.1/files/global/rad/radb.ini file to substitute the “embedded” mysql code with the db2 value. The radb.ini displayed is shown in Example 3-13: Example 3-13 radb.ini file created by the installer [Settings] ODBC_Source=mysql://127.0.0.1:60000/tpmfosd?useUnicode=true&characterEn coding=UTF-8 ODBC_Username=db2inst1 ODBC_Password=A756051188AAAE66231177B230031971 2. Next we modify the radb.ini file in order to connect using the DB2 JDBC connectivity: Example 3-14 radb.ini file modified to support DB2 JDBC connection [Settings] ODBC_Source=db2://127.0.0.1:60000/tpmfosd ODBC_Username=db2inst1102 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • ODBC_Password=A756051188AAAE66231177B230031971 3. Similar changes need to be performed on the DBGW start up script created by the installer at the path /etc/init.d/dbgw. We changed the following: The way the DBGW is run. – We substituted the link to the MySQL JDBC connector with the DB2 ones from the classpath. – We substituted the parameter jdbc.drivers with the IBM DB2 JDBC type 4 class to be used. The way the java binary is found at the beginning of the script. Note: In this step, we encountered a problem, because the command which java that is run in the start up script returned an empty string, when the PATH environment variable did not contain the required value. To fix this problem, we entered the full path of the java binary for the JAVA_BIN variable in the script. This is how the /etc/init.d/dbgw appears: Example 3-15 /etc/init.d/dbgw after the customization #! /bin/sh # Copyright (c) 1998-2005 Rembo Technology SaRL, Switzerland # # /etc/init.d/dbgw # ### BEGIN INIT INFO # Provides: dbgw # Required-Start: # Required-Stop: # Default-Start: 3 5 # Default-Stop: # Description: IBM Tivoli Provisioning Manager for OS Deployment Database gateway ### END INIT INFO SYSCONFIG_FILE="/etc/sysconfig/rembovars" . /etc/rc.status rc_reset # source Rembo settings . ${SYSCONFIG_FILE} #JAVA_BIN=`which java`Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 103
  • JAVA_BIN="/usr/lib/java/jre/bin/java" DBGW_BIN="${REMBO_DIR}/dbgw.jar" DBGW_PID="${CHROOT_PREFIX}/var/run/dbgw.pid" DBGW_PARAMS=" -cp ${REMBO_DIR}/dbgw.jar:${REMBO_DIR}/db2jcc.jar:${REMBO_DIR}/db2jcc_licen se_cu.jar -Djdbc.drivers=com.ibm.db2.jcc.DB2Driver com.rembo.dbgw.Dbgw" ... Now the Tivoli Provisioning Manager for OS Deployment is correctly installed on the system. It is a good idea to configure the program to start at each system startup.3.2.4 Configuring the Tivoli Provisioning Manager for OS Deploymentenvironment In order to configure the involved components to start when the system boots, we need to customize the /etc/init.d files. The sequence of components to be started at the system boot are as follows: 1. DB2 instance 2. DBGW component 3. RbAgent component (a listener for the Rembo component) 4. Rembo component (the core of the Tivoli Provisioning Manager for OS Deployment server) Automatically starting the DB2 instance To perform this step, you can run the command db2iauto -on db2inst1 that adds a line at the end of the inittab file, as shown in Example 3-16: Example 3-16 inittab file after the db2iauto command ... ... # vbox (voice box) getty # I6:35:respawn:/usr/sbin/vboxgetty -d /dev/ttyI6 # I7:35:respawn:/usr/sbin/vboxgetty -d /dev/ttyI7 # end of /etc/inittab fmc:2345:respawn:/opt/IBM/db2/V8.1/bin/db2fmcd #DB2 Fault Monitor Coordinator104 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • We strongly suggest that you comment this line added by the command since it is not the correct way to add Linux processes at the start up sequence. Create the DB2 boot script in the /etc/init.d folder named db2 that will accept the start and stop input as follows: Example 3-17 Creating the DB2 boot script manchester:/etc/init.d # cat db2 # Script to start and stop db2 # # Name: db2 # Date: 01/09/2007 ######################################## #!/bin/sh case "$1" in start) # Start db2 su - db2inst1 -c /home/db2inst1/sqllib/adm/db2start ;; stop) # Stop db2 su - db2inst1 -c /home/db2inst1/sqllib/adm/db2stop ;; esac Then link this script from folder rc3.d and rc5.d giving it the correct priority. Since we want the DB2 to start before the Tivoli Provisioning Manager for OS Deployment environment is started and stopped, but after the Tivoli Provisioning Manager for OS Deployment environment is shutdown, we give it the highest priority at start up creating the following links: Example 3-18 Creating links manchester:/etc/init.d/rc3.d # ln -s S03db2 ../db2 manchester:/etc/init.d/rc5.d # ln -s S03db2 ../db2 And the lowest priority at shut down with the following links: Example 3-19 Creating links manchester:/etc/init.d/rc3.d # ln -s K22db2 ../db2 manchester:/etc/init.d/rc5.d # ln -s K22db2 ../db2Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 105
  • Automatically starting the Tivoli Provisioning Manager for OS Deployment components Now that the DB2 is correctly configured, we have to set the correct priority for the Tivoli Provisioning Manager for OS Deployment scripts automatically created by the setup command. Example 3-20 shows how the rc3.5 and rc5.d folders displayed at the end of our configuration. Since they have the same values for the involved scripts, we insert only one directory listing: Example 3-20 /etc/init.d/rc3.d and /etc/init.d/rc5.d folders ... ... lrwxrwxrwx 1 root root 8 Jan 9 20:41 K21rembo -> ../rembo lrwxrwxrwx 1 root root 10 Jan 9 20:41 K21rbagent -> ../rbagent lrwxrwxrwx 1 root root 7 Jan 9 20:41 K21dbgw -> ../dbgw rwxrwxrwx 1 root root 6 Jan 11 01:44 S03db2 -> ../db2 lrwxrwxrwx 1 root root 6 Jan 11 01:44 K22db2 -> ../db2 rwxrwxrwx 1 root root 8 Jan 11 17:41 S21rembo -> ../rembo lrwxrwxrwx 1 root root 10 Jan 11 17:41 S21rbagent -> ../rbagent lrwxrwxrwx 1 root root 7 Jan 11 17:41 S21dbgw -> ../dbgw At the next startup, the ps -ef command should return a list similar to the following: Example 3-21 ps -ef output after system reboot root 2482 1 0 Jan11 ? 00:00:00 db2wdog db2inst1 2542 2482 0 Jan11 ? 00:00:00 db2sysc root 2543 2542 0 Jan11 ? 00:00:00 db2ckpwd root 2544 2542 0 Jan11 ? 00:00:00 db2ckpwd root 2545 2542 0 Jan11 ? 00:00:00 db2ckpwd root 2546 2542 0 Jan11 ? 00:00:00 db2gds db2inst1 2547 2542 0 Jan11 ? 00:00:01 db2ipccm db2inst1 2548 2542 0 Jan11 ? 00:00:00 db2tcpcm db2inst1 2549 2542 0 Jan11 ? 00:00:00 db2tcpcm db2inst1 2562 2542 0 Jan11 ? 00:00:00 db2resync db2inst1 2563 2546 0 Jan11 ? 00:00:00 db2srvlst db2inst1 2565 2542 0 Jan11 ? 00:00:00 db2hmon ... ... ...106 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • root 3954 1 0 Jan11 ? 00:00:54 /usr/lib/java/jre/bin/java -cp /usr/local/tpmfos-5.1/dbgw.jar:/usr/local/tpmfo ... ... root 4018 1 0 Jan11 ? 00:00:00 /usr/local/tpmfos-5.1/rbagent -s 127.0.0.1 BE82E15372D5192E7E9EEDE37F285C39 ... ... root 4038 1 0 Jan11 ? 00:01:00 /usr/local/tpmfos-5.1/rembo db2inst1 4057 2549 0 Jan11 ? 00:01:39 db2agent (tpmfosd) db2inst1 4058 2546 0 Jan11 ? 00:00:00 db2loggr (TPMFOSD) db2inst1 4059 2546 0 Jan11 ? 00:00:05 db2loggw (TPMFOSD) db2inst1 4060 2546 0 Jan11 ? 00:00:00 db2lfr (TPMFOSD) db2inst1 4061 2546 0 Jan11 ? 00:00:00 db2dlock (TPMFOSD) db2inst1 4062 2546 0 Jan11 ? 00:00:00 db2pfchr db2inst1 4063 2546 0 Jan11 ? 00:00:00 db2pfchr db2inst1 4064 2546 0 Jan11 ? 00:00:00 db2pfchr ... ... root 25205 24906 0 21:19 pts/1 00:00:00 ps -ef Notice that the sequence of process spawned by the system is how we defined it: first the DB2 processes, then the DBGW process followed by the RbAgent and the Rembo components.3.2.5 Run the Tivoli Provisioning Manager for OS Deploymentenvironment After each reboot you should have a running environment since the startup scripts are run by the system. However you can start stop each component in two ways: Using the startup script in the /etc/init.d folder Manually from command line To start and stop each script you can simply insert the script name followed by the start or stop argument. Remember to follow the correct sequence when starting or stopping each component, as shown in Example 3-22: Example 3-22 Correct sequence when starting or stopping each component manchester:/etc/init.d # rembo stop Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 107
  • manchester:/etc/init.d # rbagent stop manchester:/etc/init.d # dbgw stop manchester:/etc/init.d # db2 stop .. .. manchester:/etc/init.d # db2 start manchester:/etc/init.d # dbgw start manchester:/etc/init.d # rbagent start manchester:/etc/init.d # rembo start Otherwise you can manually run each component involved: For the DB2 component, you have to log on as the instance owner and use the db2start and db2stop commands: Example 3-23 db2start and db2stop commands manchester:/ # su - db2inst1 db2inst1@manchester:~> db2start db2inst1@manchester:~> db2stop To start the DBGW component, you need to have the path to the Java binaries added to the $PATH environment variable and correctly set the classpath as follows: Example 3-24 Java binaries added to the $PATH environment variable manchester:/usr/local/tpmfos-5.1 # java -cp .:dbgw.jar:db2jcc.jar:db2jcc_license_cu.jar -Djdbc.drivers=com.ibm.db2.jcc.DB2Driver com.rembo.dbgw.Dbgw -d If you want to run the Rembo component, use the following: manchester:/usr/local/tpmfos-5.1 # ./rembo -d To start the RbAgent, insert the address of the Rembo server where you want to connect to (in this case it is on the same machine) and the password of the “admin” user in clear or encrypted text (the encrypted value is in the rembo.conf file of the Tivoli Provisioning Manager for OS Deployment server): manchester:/usr/local/tpmfos-5.1 # ./rbagent -s localhost:<pwd> After performing these steps you will be able to see the Web console showing the release number of the GA: it is 5.1.0.0 as shown in Figure 3-15 on page 109.108 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 3-15 The Web console showing the build number3.2.6 Upgrade to fixpacks Each fixpack that is delivered for the Tivoli Provisioning Manager for OS Deployment (currently only Fixpack 1 is available) must be installed on top of the GA release (the 5.1.0.0). This means that you can install the Fixpack 1 on the GA release and that will bring the version to 5.1.0.1 release. When Fixpack 2 becomes available, you first need to remove Fixpack 1 and then install Fixpack 2 on top of the GA release 5.1.0.0. As you will see in the next steps, each fixpack creates a backup of the GA binaries in order to restore them when you decide to upgrade to the next fixpack. We upgraded our environment to the Tivoli Provisioning Manager for OS Deployment Fixpack 1 and below we show the procedure we performed: First of all we stop the Tivoli Provisioning Manager for OS Deployment services in the following order (see Example 3-25 on page 110): 1. RbAgent 2. Rembo 3. DBGW Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 109
  • Example 3-25 Stopping the Tivoli Provisioning Manager for OS Deployment services manchester:/etc/init.d # ./rbagent stop Shutting down IBM Tivoli Provisioning Manager for OS Deployment Web interface extension manchester:/etc/init.d # ./rembo stop Shutting down IBM Tivoli Provisioning Manager for OS Deployment server manchester:/etc/init.d # ./dbgw stop Shutting down IBM Tivoli Provisioning Manager for OS Deployment Database gateway Unpack the Fixpack 1 archive named 5.1.0-TIV-TPMOSD-linux-FP0001.tar on top of the Tivoli Provisioning Manager for OS Deployment root directory (by default /usr/local/tpmfos-5.1). In the last step we run the ifixapply command: Example 3-26 Upgrading to Fixpack 1 manchester:/usr/local # ls . .. 5.1.0-TIV-TPMOSD-linux-FP0001.tar bin include man share tpmfos-5.1 TPMfOSd-5.1.000.32-linux.tar games lib sbin src manchester:/usr/local # tar -xvf 5.1.0-TIV-TPMOSD-linux-FP0001.tar ... ... ... manchester:/usr/local # cd tpm* manchester:/usr/local # ./ifixapply ... ... ... manchester:/usr/local/tpmfos-5.1 # ls . datafile docs ifixremove radsync.nc110 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • rdf setup .. db2jcc.jar files netclnt rbagent rembo ITPMOSD0501.sys2 db2jcc_license_cu.jar ga netdebug rbagent.log rembo.conf LICENSE-AGREEMENT dbgw.jar hostsync.nc packages rbcc scripts NOTICES ifixapply pcheck rbnetfs.so server.db As you can see the “ga” folder contains the replaced binaries that will be restored when running the ifixremove command. Since each fixpack is built on top of the GA release, this should be the same behavior for all the subsequent fixpacks. Remember that the prerequisite is to install each fixpack on top of the GA version. That means that you need to remove the old one before installing the new one. Figure 3-16 on page 112 shows the Web console with the Tivoli Provisioning Manager for OS Deployment release after the upgrade to Fixpack 1, which is 5.1.0.1.Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 111
  • Figure 3-16 The Web console showing the build number after the installation of Fixpack 13.3 Initial login and installation verification Regardless of the platform that you install Tivoli Provisioning Manager for OS Deployment server on, you should verify the installation. This section contains information on how to perform an initial log on to the administrative console and verify the installation.3.3.1 Connecting using HTTPS After the server is successfully installed, log on to the Web console and verify the installation. 1. You can access Tivoli Provisioning Manager for OS Deployment administrative console using following the following URL: http://server_hostname_or_ip:port_number (e.g. http://nice:8080) If you enabled HTTPS access you will most likely receive a warning in your browser about the untrusted certificate. This is because the certificate used to encrypt the connection is a self-signed certificate and you do not have it in112 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • your Trusted Root Certification Authorities store. The warning in Internet Explorer® looks similar to Figure 3-17. Figure 3-17 Certificate warning 2. It is safe to click Yes here. 3. If you do not want this pop-up to reappear every time you connect to the server, you can import the certificate to your Trusted Root Certificate Authorities store. Go to step 4. 4. On the warning screen click View Certificates. This opens a new window with detailed information on the certificate. 5. Click Install certificate... 6. When you get to the screen where you can choose the certificate store, select Automatically select the certificate store based on the type of certificate. 7. Finish the installation of the certificate by clicking Next, and then click Finish. 8. At the end of this process you will get a final prompt asking whether you want to install this certificate or not. Click Yes. This process imports Tivoli Provisioning Manager for OS Deployment server certificate to your browser, so you will not get the security alert again.3.3.2 Installation verification The easiest way to check which version is currently installed is to look at the login screen of the Web console (does not require login). The version information is next to the username and password fields. This is useful when you want to quickly check the current version of the product (for example after fixpack installation). See Figure 3-18 on page 114. Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 113
  • Figure 3-18 Tivoli Provisioning Manager for OS Deployment version To verify your installation, log into the console using the administrative username and password you supplied during the installation. On the left side of the console click the Server status, and then click Installation check. You should see a screen similar to Figure 3-19. Figure 3-19 Verification of successful installation114 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 3.4 Advanced DHCP options Configuring your DHCP infrastructure to support PXE servers is usually limited to adding option 60 depending on where the PXE server is located. In order to support PXE clients on a network, the DHCP server is usually configured in one of the following three modes: 1. Option 60 not set, Option 43 not set 2. Option 60 set to PXEClient, Option 43 not set 3. Option 60 set to PXEClient, Option 43 set When option 60 nor option 43 is set, PXE clients will have no clue where the PXE server is, and they will therefore wait until a PXE server contacts them. In this mode, the PXE server must listen to DHCP discovery packets sent by PXE clients and answer at the same time as the DHCP server does. This mode of operation is called DHCPProxy. Communication between client, DHCP, and Tivoli Provisioning Manager for OS Deployment server in this case has the following steps: 1. The PXE enabled NIC on the client machine broadcasts the DHCP request to the network. 2. The DHCP server recognizes the request and replies to the client. Since option 60 is not set, the client waits to be contacted by Tivoli Provisioning Manager for OS Deployment server. 3. At the same time the server recognizes the DHCP request and sends the PXE parameters to the client. 4. The client contacts Tivoli Provisioning Manager for OS Deployment server using the address received by the Tivoli Provisioning Manager for OS Deployment server. It initiates TFTP file transfer to download theTivoli Provisioning Manager for OS Deployment client. 5. The Tivoli Provisioning Manager for OS Deployment client is downloaded to client machine using TFTP. Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 115
  • Figure 3-20 Option 60 not set, Option 43 not set It is obvious that this mode of operation can only be used when Tivoli Provisioning Manager for OS Deployment server is able to listen to the client’s DHCP broadcasts. If the server is in a different VLAN (virtual LAN) separated by a firewall and so on and can’t hear the client’s broadcasts, you will have to use option 43 and option 60 as described as follows. When option 60 is set to PXEClient, it means that the DHCP server knows where the PXE server is. If option 43 is not set, the PXE server is on the same computer as the DHCP server (same IP address). Communication between the client, the DHCP, and Tivoli Provisioning Manager for OS Deployment server in this case has the following steps: 1. The PXE enabled NIC on the client machine broadcasts DHCP request to network. 2. The DHCP server recognizes the request and replies to the client. Option 60 is set to PXEClient. Since option 43 is not set, the Tivoli Provisioning Manager for OS Deployment server must be on the same IP as the DHCP server. 3. The client contacts the Tivoli Provisioning Manager for OS Deployment server using the DHCP server address. It initiates TFTP file transfer to download the Tivoli Provisioning Manager for OS Deployment client. 4. The Tivoli Provisioning Manager for OS Deployment client is downloaded to the client machine using TFTP.116 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 3-21 Option 60 set, Option 43 not set If option 43 is set, PXE clients must decode option 43 to know how to reach the PXE server. In most situations, option 43 does not need to be set up, because the PXE server will either listen to the DHCP discovery packets (DHCPProxy) or be on the same computer as the DHCP server. However, if the PXE server is on a separate subnet (it cannot listen to DHCP discovery packets) or if there are several PXE servers on the same subnet, option 43 is the only viable solution to instruct PXE clients on what to do. Figure 3-22 Option 60 set, Option 43 set Communication between the client, the DHCP, and the Tivoli Provisioning Manager for OS Deployment server in this case has the following steps:Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 117
  • 1. The PXE enabled NIC on the client machine broadcasts the DHCP request to the network. 2. The DHCP server recognizes the request and replies to the client. Option 60 is set to PXEClient. Option 43 is set as well, telling the client where to look for the Tivoli Provisioning Manager for OS Deployment server. 3. The client contacts the Tivoli Provisioning Manager for OS Deployment server using the address specified in option 43. It initiates TFTP file transfer to download the Tivoli Provisioning Manager for OS Deployment client. 4. The Tivoli Provisioning Manager for OS Deployment client is downloaded to the client machine using TFTP. Option 43 is a binary buffer, containing a list of sub-options. Sub-options are packed in the binary buffer in no specific order. Most sub-options are optional. An exhaustive list of sub-options can be found in the PXE specifications. We will only describe sub-options that are of interest in order to specify the IP address of the PXE server. Other configurations, like multicast discovery, multiple unicast servers, or multiple choices are not shown here. PXE option 6: PXE_DISCOVERY_CONTROL. This option tells the PXE client how to contact PXE servers using unicast, multicast, or broadcast. In our example, we will use the value 7, meaning use PXE_BOOT_SERVERS list, disable multicast and broadcast discovery. The format of this option is one byte. PXE option 8: PXE_BOOT_SERVERS. This is a list of IP addresses, each address corresponding to one PXE server (when discovery_control is unicast). A PXE server is identified by a number (Rembo is 15) and its IP address. In our example, we will only use one IP address, the address of the PXE server we want to use for the host, which will receive these DHCP options. The format of this option is two bytes for the server type (15 for Rembo), one byte for the number of servers to list (1 in our example), and four bytes per server address. In our example, the total length of this option is seven bytes. PXE option 9: PXE_BOOT_MENU. This option contains a list of choices to prompt on the screen at boot time. In our example, we will have only one line that will go to server type 15 (Rembo). We need to have a PXE boot menu even if we do not use it (for example, boot straight on the first line of the menu). The format of this option is two bytes for the server type (15 for Rembo), one byte for the length of the string to display and the string to display on screen. In our example we use RB as the string to display. The total length of this option is therefore five. PXE option 10 (0A): PXE_BOOT_TIMEOUT. This option is required to specify how long (in seconds) the boot menu is displayed and the text of a prompt that is displayed during the waiting time. If time out is set to 0 seconds, it means that we118 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • do not want to wait, but we want to boot using the first line of the boot menu. The prompt text is not displayed, but it must be at least one character long. In our example, we will set the prompt to ‘R’. The format of this option is one byte for the time out value, followed by the prompt text. If the time out value is FF, then the menu is presented and the PXE client waits indefinitely for user selection. In our example, the total length for this option will be two bytes (one for time out and one for letter ‘R’). PXE option 255 (FF): PXE_END. The binary buffer of DHCP option 43 must end with FF in order to be valid. In addition to the standard PXE server type 15, the IBM Tivoli Provisioning Manager for OS Deployment servers accept any number between 33008 (80F0 in hexadecimal) and 33280 (8200 in hexadecimal). These PXE server type numbers are used to differentiate multiple Tivoli Provisioning Manager for OS Deployment servers in the BOOT_SERVERS sub-option of DHCP option 43. The BOOT_SERVERS sub-option consists of a PXE server type number followed by one or more server IP addresses. If the administrator wants to display two lines in the menu, pointing to two separate servers, the two servers must use different PXE server type numbers or they will be seen as only one server by the PXE network card. First example - single PXE server, no menu Now that we have described the options, let us try to build the binary buffer for option 43 for the following example: we want to have clients A and B boot on server 192.10.10.10 and clients C and D boot on server 192.10.11.10, which is on a different subnet (a valid gateway must be set up for C and D in order to communicate with the PXE server on a different subnet). We do not want menus. We just need to point clients to the correct server. Figure 3-23 PXE booting across subnets using options 43 and 60Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 119
  • Following are the options we have to insert in the binary buffer, along with their values: Note: Server type 15 is translated into 00:0F in hexadecimal. IP address 192.10.10.10 is translated into C0:0A:0A:0A and 192.10.11.10 is translated into C0:0A:0B:0A. Letters R and B are translated into 52 and 42. PXE option 6, length 1, value = 07 PXE option 8, length 7, value = 00:0F:01:C0:0A:0A:0A (clients A and B) PXE option 8, length 7, value = 00:0F:01:C0:0A:0B:0A (clients C and D) PXE option 9, length 5, value = 00:0F:02:52:42 PXE option A, length 2, value = 00:52 PXE option FF, to close the buffer The format of the binary buffer that we must use for DHCP option 43 is similar to what is used for the DHCP packet itself: the buffer is a list of options, each option starting with its option number (one byte), followed by its length (one byte), and its value (a list of bytes). Following is the transcription of the above example, for clients A and B: Option 43 = 06:01:07:08:07:00:0F:01:C0:0A:0A:0A:09:05:00:0F:02:52:42:0A:02:00:52:FF And for clients C and D: Option 43 = 06:01:07:08:07:00:0F:01:C0:0A:0B:0A:09:05:00:0F:02:52:42:0A:02:00:52:FF If your DHCP server is running on Windows NT®, you can enter these values one-by-one in option 43 by selecting hexadecimal input. If your DHCP server is ISC DHCP (version 2.x), then you can enter the above strings as is (bytes separated with colons) for parameter vendor-encapsulated-options (exact name depending on the version you are using). If your DHCP server is ISC DHCP (version 3.x), then you can use the explicit syntax to describe the PXE options, as follows in Example 3-27 on page 121.120 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Example 3-27 PXE options # In the global section: option space PXE; option PXE.discovery-control code 6 = unsigned integer 8; option PXE.boot-server code 8 = { unsigned integer 16, unsigned integer 8, ip-address }; option PXE.boot-menu code 9 = { unsigned integer 16, unsigned integer 8, text}; option PXE.menu-prompt code 10 = { unsigned integer 8, text }; # In the scope/host section: option dhcp-parameter-request-list 60,43; option vendor-class-identifier "PXEClient"; vendor-option-space PXE; option PXE.discovery-control 7; option PXE.boot-server 15 1 192.160.160.160; # address of Rembo server option PXE.boot-menu 15 5 "Rembo"; option PXE.menu-prompt 0 "Rembo"; Second example - multiple PXE servers with menu Let us consider the following example: a specific PXE computer has to show a text mode menu with two lines, each line corresponding to a different IBM Tivoli Provisioning Manager for OS Deployment server. In this example, the first server is at the address 172.30.30.101 (AC:1E:1E:65 in hexadecimal), and the second server is at the address 172.30.30.102 (AC:1E:1E:66 in hexadecimal). Following is what needs to be done: 1. Assign a boot server type to each of the servers. Tivoli Provisioning Manager for OS Deployment servers accept server type 15 and server types from 33008 to 33280. For our example, we will use 33009 (80F1) for the first server, and 33010 (80F2) for the second server. 2. Configure the sub-options of DHCP option 43 as follows: – PXE option 6, length 1,value = 07 – PXE option 8, length 14 (0E), value = 80:F1:01:AC:1E:1E:65:80:F2:01:AC:1E:1E:66 – PXE option 9, length 22 (16), value = 80:F1:08:53:65:72:76:65:82:20:41:80:F2:08:53:65:72:76:65:82:20:42 – PXE option A, length 7, value =0F:53:65:6C:65:63:74 – PXE option FF, to close the bufferChapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 121
  • Following are some details: Option 6, with a value of 7, is used to configure the PXE boot discovery in unicast mode using the option 8 for the list of available servers. Option 8 defines the two PXE servers. The first server is defined by the first 7 bytes, starting with the boot server type (80:F1, 33009), followed by one IP address: AC:1E:1E:65 (172.30.30.101). The second server is defined in the same manner, using boot server type 80:F2 (33010) and IP address AC:1E:1E:66 (172.30.30.102). Option 9 defines the boot menu that is displayed at boot time. The first 11 bytes correspond to the first line, for the first server. It shows the string Server A associated with type 80:F1 (first server). The second line shows the string Server B, associated with type 80:F2 (second server). Option 10 (0A) specifies a 15 second time out and shows the string Select as the boot menu prompt. The full option 43 would read as shown in Example 3-28. Example 3-28 option 43 06:01:07:08:0E:80:F1:01:AC:1E:1E:65:80:F2:01:AC:1E:1E:66:09:16:80:F1:08 :53:65:72:76:65:72:20:41:80:F2:08:53:65:72:76:65:72:20:42:0A:07:0F:53:6 5:6C:65:63:74:FF Tip: You can use multiple lines in the menu prompt to start new line insert codes for new line and carriage return (0A:0D). We used the following option 43 code in the lab. You can find the resulting menu in Example 3-29. Example 3-29 Resulting menu 06:01:07:08:0E:80:F1:01:AC:1E:1E:65:80:F2:01:AC:1E:1E:65:09:26:80:F1:13 :54:50:4D:4F:53:44:20:2D:20:6D:61:6E:63:68:65:73:74:65:72:80:F2:0D:54:5 0:4D:4F:53:44:20:2D:20:6E:69:63:65:0A:4A:FF:28:5F:5F:29:0A:0D:28:6F:6F: 29:0A:0D:20:5C:2F:2D:2D:2D:2D:2D:2D:2D:5C:0A:0D:20:20:7C:7C:20:50:58:45 :20:7C:20:5C:0A:0D:20:20:7C:7C:2D:2D:2D:2D:7C:7C:20:20:2A:0A:0D:20:20:5 E:5E:20:20:20:20:5E:5E:0A:0D:53:65:6C:65:63:74:3A:FF122 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 3-24 Menu showing two PXE servers3.5 Web interface extension The Web interface extension is an optional component that can run under most operating systems. When installed, it can be used by the Tivoli Provisioning Manager for OS Deployment server to perform actions on remote computers and to gather information from remote computers. For example, it is responsible for restarting the computer when a deployment starts or for performing an operating system inventory. Tip: Web interface extension is usually called RbAgent. It is called this way because that is the name of the Web interface extension executable. Credentials used to run the Web interface extension must be sufficient to browse, read, and write directories you want to be accessible remotely. The most important use of the Web interface extension is to access the server files from your browser. It is used to transfer files between the computer running the browser and the server. When the Web interface extension is not installed on the computer running the browser you cannot do the following from that machine: Browse, download to, or upload from machines other than server when using features like “RAD Export” or “RAD Import”. You can still use these features using file systems on the server. Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 123
  • Create unattended profiles and image file clone profiles. To create profiles of this type, Web interface extension has to be installed on the machine from which you connect to the server.3.5.1 Installing on Windows systems This section guides you through the installation steps of the Web interface extension on a client. 1. There is an easy way to verify if the Web interface extension is already installed. Go to Server status → Web interface extension. If you do not have Web interface extension installed on your machine you will see a screen similar to Figure 3-25. 2. If you do not have Web interface extension installed, you can download and install it from the Tivoli Provisioning Manager for OS Deployment server. Click the link named Click here to download the Web interface extension installer for Windows to download the Web interface extension from the server. Figure 3-25 Web interface extension download for Windows 3. After starting the installation using the rbagent.msi file, select the installation language, and click Next when prompted in the welcome wizard. 4. Select I accept the terms in the licence agreement, and click Next.124 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 5. When the server configuration screen, as shown in Figure 3-26, appears specify the server IP address (not host name) and administrator password on this screen. Attention: You must specify the IP address and NOT the hostname in the Server IP Address field. If you specify the hostname, Web interface extension cannot connect to the server. Figure 3-26 Server connection parameters 6. Next, enter credentials for Web interface extension service. See Figure 3-27 on page 126. When Web Interface Extension service is started, it runs in context of the user specified here. We recommend that you use an unprivileged account that has access only to files and directories related to the Tivoli Provisioning Manager for OS Deployment. If you do not need to browse file systems on this machine and only want to use extension for remote reboots and inventory, you can leave these fields empty. Service will then run in context of Local System.Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 125
  • Figure 3-27 User account specification 7. Click Install, and then Finish. The two following screens will lead you to the end of installation. After Web interface extension is installed you will see a screen similar to Figure 3-28 on page 127. This confirms that the agent was successfully installed and has connected to server.126 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 3-28 Windows Web Interface Extension version installed You can find your newly installed Web interface extension in directory %ProgramFiles%Common FilesIBM Tivoli. This directory contains the following three files: rbagent.exe - Web interface extension executable. rbagent.conf - agent configuration file that contains the IP address of the server and an encrypted password for connection to the Tivoli Provisioning Manager for OS Deployment server. rbagent.log - agent log file that is recreated each time service is started. The service name of the Web interface extension depends on the service pack level you are using. It is named “Rembo Agent” (older name) or “IBM Tivoli Web Interface Extension” (new name).3.5.2 Installing on Linux systems This section guides you through the steps to install the Web Interface Extension on a client. Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 127
  • 1. There is an easy way to verify if the Web interface extension is already installed. Go to Server status → Web interface extension. If you do not have the Web interface extension installed on your machine you will see a screen similar to Figure 3-29. 2. If you do not have the Web interface extension installed you can download and install it from the Tivoli Provisioning Manager for OS Deployment server. Click the link named Click here to download the Web interface extension installer for Windows to download the Web interface extension from the server. Figure 3-29 Web interface extension download for Linux The file you downloaded is not an installer—it is rbagent executable you can run immediately. This kind of distribution (not using RPM or DEB packages) allows usage on larger number Linux distributions. However, it also means that for some Linux distributions you have to create startup scripts manually. Startup scripts for Debian, RedHat, and Suse can be found in the server installation package for Linux. Here is a short example of the rbagent init.d script that should work in most Linux distributions. Adjust paths in the variables and IP address of the server to suit your environment.128 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Example 3-30 Sample rbagent startup script #! /bin/sh # exit on any error set -e # get rbagent configuration variables . /etc/rbagentvars RBAGENT_BIN="${TPMOSD_DIR}/rbagent" RBAGENT_PID="/var/run/rbagent.pid" RBAGENT_CONF="${TPMOSD_DIR}/rbagent.conf" RBAGENT_PARAMS="-s 1.2.3.4:${TPMOSD_PWD}" NAME=rbagent SCRIPTNAME=/etc/init.d/$NAME PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:$TPMOSD_DIR # Gracefully exit if the package has been removed. test -x $RBAGENT_BIN || exit 0 case "$1" in start) echo -n "Starting $NAME" ${RBAGENT_BIN} ${RBAGENT_PARAMS} echo "." ;; stop) echo -n "Stopping $NAME" kill `cat ${RBAGENT_PID}` echo "." ;; *) echo "Usage: $SCRIPTNAME {start|stop}" >&2 exit 1 ;; esac exit 0 This script uses a configuration file with rbagent configuration variables. The file is called rbagentvars and is placed in the /etc directory. Example 3-31 shows sample contents of that file. Example 3-31 Configuration variables in /etc/rbagentvars # rbagent startup script configuration variables REMBO_DIR="/opt/rbagent"Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 129
  • REMBO_PWD="BE82E15372D5192E7E9EEDE37F285C39" Finally, if you want rbagent to automatically start and stop when you restart the machine, then link this script to rcX.d directories, where X is the runlevel number. The files in these directories are used to control programs (start/stop) according to the runlevel system entered. You can find more information on runlevels by running the man init command on a Linux system. Note: The Web interface extension tries to read DMI information when doing the inventory of the machine. To do so it requires root privileges. If security is an issue you can run rbagent in context of a non-root account. Everything will function normally but you cannot collect DMI information. Example 3-32 contains commands you can use to create links to startup script. Note that some scripts start with the letter K while others start with the letter S. This is an indication whether in that runlevel process should be started (S) or killed (K). You have to run these commands as root in order to be able to write to /etc/rc.d/rcX.d directories. Example 3-32 Linking rbagent startup script to rc.d directories cd /etc/rc.d/rc0.d && ln -s ../../init.d/rbagent K33rbagent cd /etc/rc.d/rc1.d && ln -s ../../init.d/rbagent K33rbagent cd /etc/rc.d/rc2.d && ln -s ../../init.d/rbagent S66rbagent cd /etc/rc.d/rc3.d && ln -s ../../init.d/rbagent S66rbagent cd /etc/rc.d/rc5.d && ln -s ../../init.d/rbagent S66rbagent cd /etc/rc.d/rc6.d && ln -s ../../init.d/rbagent K33rbagent3.5.3 Running rbagent from command line Web interface extension, even though its name does not suggest so, can also be run from command line. This might be useful if you need to use some of the Tivoli Provisioning Manager for OS Deployment features from the command line. Note: Not all rbagent commands are intended to be run interactively. Most of these commands are used in scripts during the deployment of machines. Be sure you know what you are doing before using any of the rbagent commands on your machine. As previously mentioned, the rbagent command is mostly run automatically in deployment scrips; however, there are few useful commands that can be run interactively or in user scripts.130 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • To get a list of the rbagent’s command switches you can run rbagent -h command. The following example shows a list of command line switches for rbagent. Example 3-33 RbAgent command line switches C:Program FilesCommon FilesIBM Tivoli>rbagent.exe -h IBM Tivoli Provisioning Manager for OS Deployment Web extension v.5.1.0.1 (101.04) Licensed Materials - Property of IBM. L-DDAC-6RLW3E (C) Copyright IBM Corporation 1998, 8 2007. All Rights Reserved. IBM, the IBM logo, and Tivoli are trademarks of IBM Corporation in the United States, other countries or both. usage: rbagent [-d] [-v loglevel] [-q] [-o] [-f iface] -s srvip:password [-p srvport] [arguments] -d: enable debugging mode, do not detach -v: set logging verbosity (1-6) -q: quiet (do not display banner) -o: run in offline mode (no connection to the server) -f: iface is the IP address of the preferred interface/subnet to use -s: srvip is an IP address, password can be plaintext or MD5 -p: srvport is then NBP port of the server arguments are optional supported operations C:Program FilesCommon FilesIBM Tivoli> As you can see from the help switches, rbagent can work in online (requires connection to the Tivoli Provisioning Manager for OS Deployment server) and offline mode (does not require connection to the Tivoli Provisioning Manager for OS Deployment server). To use offline mode, use -o switch. To use rbagent in online mode and connect to the server, you have the following two options: Specify -s switch to explicitly define which server you want to connect to and which password to use. Start rbagent without -s switch and the server connection parameters will be read from the rbagent.conf file. RbAgent does not have an explicit help command; rather, it lists all available commands if input was not recognized. To get a list of available commands, you can use any word that is not a known command. The list of commands you get depends upon whether you are using offline or online mode. The list of online mode commands contains all commands from offline mode and commands available only when connected to server. The following example is a result of running rbagent -q -s 172.20.20.101:password command and lists all online and offline commands. To get a list of only offline commands, run rbagent -o help command.Chapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 131
  • Example 3-34 Commands available in rbagent Connect 172.20.20.128 -> 172.20.20.101 Starting Rembo Agent [10:27:36] <ERR> Invalid RbAgent command: help Known commands: report : update agent status on the server process-commands : process pending server commands hostinfo : display general information on the machine radget : download a .RAD archive from the server radput : upload a .RAD archive to the server radcheck : verify the consistency of a .RAD archive radunpack : explode the content of a .RAD archive on a local path mkimage : create a rembo archive from a local drive rsimage : restore a rembo archive to a local drive isoget : generate an ISO image from server files buildpcidb : create a PCI database export from a text file install-kernel : install rembo on a system partition install-archive : install an archive on a local partition create-cdrom : create a bootable cdrom fallback-mbr : disable hard disk boot with a fall back MBR cmdlines : process a rbagent command lines file joindomain : join a Windows domain resetminisetup : reset the mini-setup progress flag checkdevices : look for devices not functioning properly instwimgapi : install Microsoft Windows Imaging DLL and file driver rad-radinfo : describe the logical content of a .RAD archive rad-radput : upload a .RAD archive to the server, with ODBC records rad-radget : download a .RAD archive from the server, with ODBC records rad-srvradput : asynchronously upload a .RAD archive on the server, with ODBC records rad-isoget : build an ISO image from the server, with ODBC records rad-chksoft : simulate the creation of a new software package rad-mksoft : create a new software package rad-mkwinsetup : create a Windows setup image rad-mkvistaclone : create a Windows Vista WIM image rad-mklinuxsetup : create a Linux setup image rad-mksolarisboot : create a Solaris boot image rad-jumpstart-pre : generate Jumpstart pre-installation files rad-jumpstart-post : upload Jumpstart logs to the server rad-uploadlogs : send local log files to the server rad-deployhost : trigger a client deployment on the server rad-hoststatus : get the deployment status for a client rad-hostlogs : get the deployment logs for a client rad-schemelist : list all deployment schemes registered in the database rad-configlist : list all OS configurations registered in the database rad-serverlist : list all RAD servers registered in the database rad-srvsync : trigger a server file synchronization process132 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • rad-hostlist : list some hosts registered in the database rad-registerhost : update a client record in the database rad-unregisterhost : remove a client record from the database rad-hidepassword : return the encoded form of a password as used internally rad-configure : force server to reload radconfig.csv rad-mkbootcd : create a bootable CD-ROM to start RAD without PXE rad-runtask : execute any pending activity Stopping Rembo Agent Each command has a short description next to it, so you can easily see what it is used for. Most of these commands require additional parameters. If a command requires additional parameters, you will get a list of parameters when you start the command. Following is an example for running the following command: rbagent -q -s 172.20.20.101:password rad-hidepassword Example 3-35 Help on rad-hidepassword command Connect 172.20.20.128 -> 172.20.20.101 Starting Rembo Agent [11:35:08] <ERR> usage: rad-hidepassword <password> [md5] [11:35:08] <ERR> RbAgent command rad-hidepassword has failed [AGT:1788] Stopping Rembo Agent Notice the line starting with usage—this is a usage explanation for the command. You can see that the command requires a password attribute, which can optionally be followed by keyword md5 that causes the password to be encrypted using MD5. Now that we know how to connect to the server and list known commands it is time to list the commands you might find useful. Please remember that you need to prefix these commands with rbagent and any command switches you would like to use (for example rbagent -s srvip:password). Indicate whether the command can be run offline or online and can be found in brackets next to the command name. radunpack (OFFLINE) - this command allows you to unpack RAD files to the local directory. This can be useful if you just need some files from the RAD archive and do not want to import the RAD file to the server and use it in deployment. The syntax of this command is as follows: radunpack radfilename.rad local-destination-pathChapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 133
  • joindomain (OFFLINE) - it is not very likely you will have to run this command manually since you can make the machine join the domain when it is deployed. However, it is good to know this command exists in rbagent should you decide to use it later manually or from some other configuration management tool. The syntax of this command is as follows: to join domain: joindomain domain adminuser adminpwd [joinou] to join a workgroup: joindomain /w workgroup [adminuser adminpwd] to change the trust account: joindomain /s domain trustpwd rad-mksoft (ONLINE) - use this command to manually build software packages. “Example - registering hosts from the command line” on page 134 shows how to automatically build device driver software packages using this command. The syntax of this command is as follows: rad-mksoft sourcepath ["<attr>=value" ...] <attr> is in (descr,content,pkgname,dest,cmdline, pass,flags,dosubst,norules) rad-registerhost (ONLINE) - this command is very useful if you have naming conventions where simple attribute mapping is not enough. If you use scripting to create host names, you might use this command in your script to automatically register hosts to Tivoli Provisioning Manager for OS Deployment server. See the following example on how to use this command in scripts. The syntax of this command is as follows: rad-registerhost <IP|MAC|SN|UUID>=... [HostName=...] [...] rad-unregisterhost (ONLINE) - use this command to unregister the machine from the Tivoli Provisioning Manager for OS Deployment server. You might use it for automatic maintenance of the hosts list (for example, to integrate with the monitoring solution to remove machines not reachable for more than 30 days). The syntax of this command is as follows: rad-unregisterhost <IP|MAC|SN|HostName|Description>=... rad-hidepassword (ONLINE) - this command is used to create an encrypted password using clear text password as input. This is very useful if you want to manually update passwords in configuration files. If you use this command to generate password for configuration files, specify the md5 keyword. The syntax of this command is as follows: rad-hidepassword <password> [md5] Example - registering hosts from the command line In this example we look at a company that has four different locations: London, Paris, Sydney, and Zagreb. They are implementing Tivoli Provisioning Manager for OS Deployment and want to register hosts with host names in accordance with their naming policy. The computer name has to take the form134 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • LLLMMMMMM where LLL is a three letter code for the location and MMMMMM is the last three octets (six hexadecimal characters) of the MAC address. When registering new hosts or assigning a name to an already registered one, you can use some special keywords that are dynamically replaced with host specific information at the time of deployment. These special keywords must be enclosed in square brackets [ ]. [IP] is replaced by the full IP address of the host being deployed, while [MAC] is replaced by the hardware address. To set hostnames based on the MAC address, you can enter the following value in the Host name field: pc[MAC]. The computer with the MAC address 00:01:02:03:04:05 will be named pc000102030405. The following keywords can be used: [IP] - the full IP address (received by DHCP) [MAC] - hardware address [SN] - serial number as found in DMI (SMBIOS) [AT] - DMI asset tag [BOM] - unique identifier in Tivoli Provisioning Manager for OS Deployment server database Every keyword supports a ’range’ extension if you want to include only part of the dynamic information. [IP3] corresponds to the last octet of the IP address (pc-[IP3] becomes pc-12 if IP address is 192.168.0.12). [IP1-3] corresponds to octets 1 to 3. [MAC4-6] is replaced by the last three digits of the MAC address. Note: The host name that uses dynamic keywords is expanded only during deployment. Do not expect it to be updated dynamically in the administrative console if no deployment has occurred. Dynamic keywords are used to get MMMMMM part of the name in our scenario. We also have to calculate the location code. We will assume that the input to the script is an IP address. The host name is generated according to the naming policy. The host is then registered to the server using the provided IP address and generated host name. Each location has different C-class subnets (netmask is 255.255.255.0) that we will use to determine the location of the machine. Following is a list of locations, location codes, and IP addresses used on that location: London (LON) - 10.1.1.x Paris (PAR) - 10.1.2.xChapter 3. Installing the Tivoli Provisioning Manager for OS Deployment environment 135
  • Sydney (SYD) - 10.1.3.x Zagreb (ZAG) - 10.1.4.x If the machine in Zagreb has the MAC address 00:01:02:03:04:05, then its name should be ZAG030405. This is done in the following two steps: 1. In the first step we do not know the MAC address of the machine, so we will leave this for the deployment phase. To determine the host name, we will use the third octet of the IP address and then register the host using the host name like LON[MAC4-6] for London machines, SYD[MAC4-6] for Sydney machines, and so on. 2. The second part of this process occurs during the deployment of machines. When the machines are deployed they will be assigned a host name according to their MAC address. Example 3-36 shows a script that converts IP to location codes and registers host machines to the Tivoli Provisioning Manager for OS Deployment server. The script accepts a single IP address as input and assumes rbagent is properly configured and can be found using your PATH variable. Example 3-36 Example script #!/bin/sh B_IP=$1 B_SUBNET=`echo $B_IP | cut -d"." -f3` case $B_SUBNET in 1) B_LOCCODE=LON;; 2) B_LOCCODE=PAR;; 3) B_LOCCODE=SYD;; 4) B_LOCCODE=ZAG;; *) exit 1;; esac B_HOSTNAME=$B_LOCCODE"[MAC4-6]" echo Registering host - IP:$B_IP, hostname:$B_HOSTNAME rbagent rad-registerhost IP=$B_IP HostName="$B_HOSTNAME" The machines are registered as LON[MAC4-6], PAR[MAC4-6], SYD[MAC4-6], ZAG[MAC4-6]. During deployment they will get names such as, LON5174BF, SYD75257A, and so on.136 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 4 Chapter 4. Installing pre-Vista systems In this chapter we discuss and describe how we install and migrate to Windows Operating systems other than Microsoft Vista. We include details of the operating system installation and also how the personality of the machine is preserved during such a migration. We also describe how such non Vista operating systems can be installed on a machine that at the time has no operating system installed. We will cover the case of server builds, where we may also have to consider the configuration of RAID arrays. The chapter has the following topics: “Introduction” on page 138 “User State Migration” on page 138 “Creating a cloned profile of Windows XP” on page 145 “Creating an unattended profile for Windows 2000” on page 171 “Real world OS installation scenarios” on page 187 “Restoring the machine’s user personality settings” on page 198© Copyright IBM Corp. 2007. All rights reserved. 137
  • 4.1 Introduction In this chapter we review the process of dealing with Windows Operating Systems, other than Windows Vista, and discuss the following scenarios: Installing Windows XP on a bare metal machine. Indentifying any differences in this process when dealing with other non-Vista Windows operating systems. Upgrading Windows 2000 to Windows XP. Preserving user preferences and data over the operating system migration.4.2 User State Migration For the migration of the machine personality, we could use different techniques. Here we opted to use the User State Migration Tool (USMT) Version 3 from Microsoft. Visit the following Web site for details about this tool: http://technet2.microsoft.com/WindowsVista/en/library/91f62fc4-621f-453 7-b311-1307df0105611033.mspx It is also possible to achieve much of the same result by using the Thinkvantage System Migration Assistant 5.2 from Lenovo. This technology is available for use on IBM X series servers and workstations, and OEM licenses can be purchased for use on equipment made by other manufacturers. Further details of the ThinkVantage System Migration Assistant can be found at the following Web address: http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo &lndocid=MIGR-66945 The installation of USMT 3.0 on Windows XP is via a simple setup command with no options. The completion of the installation process is shown in Figure 4-1 on page 139.138 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-1 Completion panel from the installation of USMT 3 There is no GUI to drive this application, but, by default, the application binaries are located at C:Program FilesUSMT30. The key files that we are concerned with are shown in Table 4-1. Table 4-1 Significant files from the installation of USMT 3.0 Name Function ScanState.exe To scan and save user settings LoadState.exe To load user settings from a saved source MigUser.xml Default policy for migration of user settings MigSys.xml Default policy for the migration of system settings MigApp.xml Default settings for the migration of applications4.2.1 Saving the personality of an XP machine We use the scanstate command to save the machine personality before we re-image it. For this to work efficiently, the command has to run in the context of an account with administrative rights because without such rights some settings will not be migrated. Remember that in the arguments passed to the command, we have to identify the desired target. The command in Figure 4-1 on page 140 explicitly prepares the backed up data ready for migration to an XP machine as Chapter 4. Installing pre-Vista systems 139
  • defined by the /targxp argument. All of the commands are included in the script in Figure 4-1. Example 4-1 Sample script to backup machine personality @echo off echo This command will backup the personality of the machine ready for migration to XP VER | FIND "Windows 2000" >NUL IF NOT ERRORLEVEL 1 ECHO Windows 2000 found, collecting data for migration to XP "C:Program FilesUSMT30scanstate" /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13 "C:Program FilesUSMT30scanstate" "itsont03Project DataTITI-7V01-OSDeploymentUSMT%COMPUTERNAME%" /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:13 /encrypt /key:"mykey" VER | FIND "Windows XP" >NUL IF NOT ERRORLEVEL 1 ECHO Windows XP found, collecting data for migration to XP "C:Program FilesUSMT30scanstate" /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13 "C:Program FilesUSMT30scanstate" "itsont03Project DataTITI-7V01-OSDeploymentUSMT%COMPUTERNAME%" /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:13 /encrypt /key:"mykey" goto :eof :nosupport ECHO We do not support this operating system VER :eof When this operation completes, you will see what is written to the screen shown in Figure 4-1. As the script was run in a context that had administrative rights, we were able to restore multiple user profiles. In real life, this operation is integrated into an automated process. This could be achieved in a number of ways: Group Policy Objects Tivoli Provisioning Manager workflows We recommend that this is done automatically outside the control of Tivoli Provisioning Manager for OS Deployment so that the profile information is available on a share when the machine is migrated and the profiles need to be restored.140 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • If you are unsure if the target workstation target will be Vista, XP, or Windows2000, you need to generate different profile archives—one for each possibility.This has to be catered for in the backup and restore scripts that pass argumentsto the scanstate and loadstate commands.Example 4-2 Results of the saving of a machines personalityC:>"C:Program FilesUSMT30backup.bat"C:>rem this will backup profiles for use in an XP machineC:>"C:Program FilesUSMT30scanstate" /targetxp /i:migsys.xml/i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13Log messages are being sent to C:Program FilesUSMT30ScanState.logScanning the computer for files and settings...ScanState has successfully created the config file at C:config.xml.C:>"C:Program FilesUSMT30scanstate" "Program filesUSMT30LION"/targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:13 /encrypt /key:"mykey"Log messages are being sent to C:Program FilesUSMT30ScanState.logScanning the computer for files and settings...Collecting files and settings for: This Computer LIONAdministrator (user 1 of 2) LIONRichard Hine (user 2 of 2)Saving files and settings - 1 minute(s) remaining...ScanState has successfully collected the files and settings.Somewhere to save our user profilesNote that we are qualifying output files of this command with fully qualified UNCnames. This avoids the need to set up an explicit network share. It does howeverassume that we have read access to the unattended share. To make sure thatthis is the case, add this share to the null session share list as defined in theLocal Security policy of the server of the share. An example of this is Figure 4-2on page 142. Chapter 4. Installing pre-Vista systems 141
  • Figure 4-2 Setting up a Null Session Share In our scripts we save away the user profile information using USMT, by directing the saved data to a network drive. There are different techniques you can use, but we are using a network drive to which all users have read and write access. We do this, as the script logs its activities back to the share. The file server is Windows 2003, and we need to perform some server administration to give us the necessary permissions. 1. We set up a share called UserMigration, and in the Security settings for the share grant everyone read and write access as seen in Figure 4-3 on page 143. If this is not valid at your site, then change the script to write their log files elsewhere. Note that the scanstate.exe command can encrypt the profile stores using a key of your choice, so even if they can ‘read’ the file, they cannot make any use of it.142 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-3 Give everyone access to the share2. For Windows 2003, we also enable the Guest Account for anonymous access to the server. This is done in the Local Users and Groups of the Computer Management console as in Figure 4-5 on page 144. Just check that the account is enabled, as by default it is disabled. See Figure 4-4 on page 144. Chapter 4. Installing pre-Vista systems 143
  • Figure 4-4 Enable the guest account on WIndows 2003 3. Check that the Windows 2003 machine has the Guest account enabled. Figure 4-5 Check guest account enabled 4. Test that this share is working, as we have shown in Figure 4-6 on page 145, where we type the contents of a file without having to explicitly authenticate with the server beforehand.144 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-6 Testing the null session share Summary Now that we saved the personality of the machine to a safe place, we can move the system from Windows 2000 to XP. We built the XP image that we used to migrate the Windows 2000 to an XP machine. Windows XP can be defined to Tivoli Provisioning Manager for OS Deployment in one of the following two ways, using different profile types: Cloned Unattended Next, we create a cloned profile containing Windows XP.4.3 Creating a cloned profile of Windows XP This process follows the following steps, which removes any personal data from the machine. Use the following steps to clean up the donor XP machine: 1. Remove any network shares. 2. Remove any remote printer definitions. Chapter 4. Installing pre-Vista systems 145
  • 3. Empty the Web browser cache. 4. Remove any user files. 5. Empty the contents of the Trash Can. Run sysprep on the donor machine to remove its identify before it is installed on other machines. The sysprep infrastructure is located in the deploy.cab file, which is under the supporttools directory of the Windows XP installation media. Expand the contents of this cab file into a new directory on the donor machine called sysprep. There are many options to this command that we do not further discuss here but are well documented at the following Web site: http://support.microsoft.com/kb/30257 With Windows XP, we used c:sysprepsysprep -quiet -mini -forceshutdown -activated -reseal, which when it has completed shutdowns the donor machine. At this point, Tivoli Provisioning Manager for OS Deployment knows nothing of this donor machine, and one way of registering it is to perform a network boot of this machine. At this point, the machine is automatically registered and picks up the Tivoli Provisioning Manager for OS Deployment PXE Client code. So, power up the donor machine again, and make sure that you boot it from the network before booting from the hard disk. If the default boot order in the BIOS is set to boot from disk first, this can usually be overwritten by selecting a special key sequence on power up. F12 or ESC are common. When the machine does a network boot, you will see it looking for a DHCP address, which when it has been allocated is followed by the Tivoli Provisioning Manager for OS Deployment PXE Client logo screen appearing on the console—much like the example in Figure 4-7 on page 147. For an unattended operation you might want to consider making starting from the network the first option in the boot sequence.146 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-7 Tivoli Provisioning Manager for OS Deployment PXE Client boot screenAt this point, we should see the following two things: We should also see a new machine appear under OS Deployment > Host Monitor with a MAC address the same as that in the Tivoli Provisioning Manager for OS Deployment client screen as in Figure 4-9 on page 149. We should also see that the Tivoli Provisioning Manager for OS Deployment PXE Client screen is locked, as shown in Figure 4-8 on page 148. Chapter 4. Installing pre-Vista systems 147
  • Figure 4-8 Tivoli Provisioning Manager for OS Deployment PXE Client locked menu. This client screen remains locked until it is released from the Tivoli Provisioning Manager GUI. It is from the Tivoli Provisioning Manager GUI that we want to start the admin toolkit (also called administrator toolkit) in order to start building the XP image profile. Tip: If you are running more than one PXE server in your environment, check that the PXE server identified in the client GUI is the one you expect to use, or you may get unpredictable results.148 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-9 Ready to start the admin toolkit on a new donor machineIn Figure 4-9 we start the admin toolkit from the context menu of the newlydiscovered machine, which you can see just behind and above the right handcontext menu. When we do this we see the information shown in Figure 4-10.Figure 4-10 Starting the admin toolkit Chapter 4. Installing pre-Vista systems 149
  • Press OK to continue, and then finally you will see the admin toolkit primary menu of the Tivoli Provisioning Manager for OS Deployment PXE Client menu, as shown in Figure 4-11. Figure 4-11 The admin toolkit primary menu Now we are ready to make the new image profile. Select Make a new image, and you are then presented with the options, as shown in Figure 4-12 on page 151.150 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-12 Admin toolkit image creation menuAfter you select Create a System Profile, you are asked to name the profile, asshown in Figure 4-13 on page 152. Chapter 4. Installing pre-Vista systems 151
  • Figure 4-13 Naming the new profile Next, we are asked for further details of the profile we are creating, including if we want to capture and use the CMOS settings from the donor machine, as shown in Figure 4-14. Be careful here if you save the CMOS settings with the profile, as this makes the profile hardware specific. There are checks that you can make during deployment to ensure that the model of the target is the same as that of the donor, which should be used if the CMOS data is captured. We suggest that the use of this feature is in the setting of the boot sequence of the target to the same as those defined in the donor machine. In this way, we can set the target to always boot from the network first. Figure 4-14 CMOS settings in the image profile152 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • We are then asked to confirm the creation of the profile in Figure 4-15.Figure 4-15 Profile creation confirmationNow we can monitor the profile creation process, as shown in Figure 4-16.Figure 4-16 Profile creation progress dialogWhen the profile creation process completes, a notification in the TivoliProvisioning Manager for OS Deployment PXE Client screen appears, as shownin Figure 4-17 on page 154. Chapter 4. Installing pre-Vista systems 153
  • Figure 4-17 Completion dialog for profile creation Finally, as you select the Main menu button you are asked the following. Figure 4-18 Admin tool exit action dialog Tip: Remember what is likely to happen. If you allow the machine to boot again from disk, you will go through the mini sysprep process as this was the donor machine. This process asks you for license keys and so forth, as though you are completing a first time installation. Decide what you are going to do with the donor machine now that you successfully created the profile. Return to the Tivoli Provisioning Manager for OS Deployment Web GUI, where you can see details of the newly created profile as shown under OS Deployment → Profiles as shown in Figure 4-19 on page 155.154 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-19 Newly created profile Now that we have a new cloned profile, we can explore and change its contents if required. Windows 2000 and 2003 When we repeat this operation, but with a Windows 2000 donor machine, we use c:sysprepsysprep -quiet -mini -forceshutdown. This completes our process of creating a clone operating system image for Wndows XP, 2000, and 2003.4.3.1 Changing the contents of the cloned machine What is different 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. Open the profile, as shown in Figure 4-20 on page 156. Chapter 4. Installing pre-Vista systems 155
  • Figure 4-20 Opening the newly created image profile When the profile is open, you will see the overview, as shown in Figure 4-21 on page 157. From here you can do the following: Add and delete directories from the image Add and delete files 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 If we edit the profile details, we can add system category information, which then allows us to associate this profile with software applications. In this way, the software applications are ‘bound’ to the image. Changes to the profile appear in Figure 4-22 on page 158.156 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-21 Overview details of the profile Chapter 4. Installing pre-Vista systems 157
  • Figure 4-22 Changing the profile details After we finish with the profile details, we can modify the details of the disk partitions in the image. This may be useful if the donor machine is much smaller than the likely targets or maybe we want to create a new partition on the target for the purposes of local redeployment. You see in Figure 4-23 on page 159 that we can add or extend a partition. The partition size can be modified by sliding the bar on the boundary of the disk in the tool. See the arrows. We recommend that you allow the disk partition to take 100% of the target disk in order to cater to different disk sizes.158 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-23 Modify the disk partitions in the profileIn Figure 4-24 on page 160, you see that we created a new partition that takes31% of the physical disk.We recommend however, that you use 100% of the available physical disk tomake the process less dependent on the physical characteristics of the target.Remember that this can be used to target the first physical disk of a machinewhile leaving the second physical disk unchanged.Note that TPM for OS Deployment does not clone from all physical disks, and if itis a requirement to install data or applications on a second physical disk, do itwith a software package. Chapter 4. Installing pre-Vista systems 159
  • Figure 4-24 Adding a new disk partition Details of how the OS is configured on the target machine is contained in the configuration profile. You see this in Figure 4-25. It is this information that is used by the mini setup process that was requested when we did the initial sysprep to build this image, and will be run when the target OS boots after initial deployment. It is at this time that the machine is given its new identity including host name and other network characteristics. Figure 4-25 Profile configuration name160 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • When you select the named profile, you will see the summary as shown inFigure 4-26.Figure 4-26 Profile configuration summaryYou see that we can make customer additions to the sysprep.inf file. Rememberthat this file is used when the image is deployed to a new target. Suchmodifications are useful to allow you to run custom actions when the deploymentis 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/duplication.mspx Chapter 4. Installing pre-Vista systems 161
  • 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 The key parameters are documented in Example 4-3. Example 4-3 Available sysprep.inf variables [Unattended] ExtendOemPartition OemPnPDriversPath OemSkipEula InstallFilesPath KeepPageFile ResetSourcePath UpdateHAL UpdateUPHAL UpdateInstalledDrivers TapiConfigured [GuiUnattended] AdminPassword Autologon AutoLogonCount OEMDuplicatorString OEMSkipRegional OEMSkipWelcome TimeZone [UserData] Supports the same set of entries as the Unattend.txt file. [LicenseFilePrintData] Supports the same set of entries as the Unattend.txt file. [GuiRunOnce] Supports the same set of entries as the Unattend.txt file. [Display] Supports the same set of entries as the Unattend.txt file. [RegionalSettings] Supports the same set of entries as the Unattend.txt file. [Networking] Supports the same set of entries as the Unattend.txt file. [Identification] Supports the same set of entries as the Unattend.txt file. [TapiLocation]162 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • [Sysprep]Automatically generates the entries in the [SysprepMassStorage]section.[SysprepMassStorage]Allows you to use the same image on computers with differentmass-storage devices.If you want to do something simple like run a script after installation completes,then see Example 4-4, which gives you the critical but incomplete items from thesysprep.inf file that you will need. In this example, we run thec:run_this_command.cmd file the first time that the target machine boots afterinstallation.Example 4-4 sysprep.inf sample[Unattended].[GuiUnattended].AutoLogonCount=1AutoLogon=Yes.[GuiRunOnce].Command0=C:run_this_command.cmd.From this same screen in Figure 4-26 on page 161, we customize the menu thatis offered to the user of Tivoli Provisioning Manager for OS Deployment whenthey select the image profile to be deployed. This is shown again in Figure 4-26on page 161. Why would we do this? To change the dialog text to make it easier for business users to understand. To add image branding to the dialogs. To password protect certain images. To add timeouts to the display for auto selection of a single-option image.This customization process starts as shown in Figure 4-27 on page 164. Chapter 4. Installing pre-Vista systems 163
  • Figure 4-27 Initial client side GUI dialog From here we can perform the customization, as shown in Figure 4-28 on page 165.164 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-28 Client side GUI customizationAfter this is complete, we can further change the profile to perform systemcustomization, as shown in Figure 4-29.Figure 4-29 Profile system customizationNext we can perform OS customization, as shown in Figure 4-30 on page 166. Chapter 4. Installing pre-Vista systems 165
  • Figure 4-30 Profile OS customization There are others you can view, but as a real example let us say that we need to append the uk.ibm.com DNS domain to the host name search order; therefore, select EDIT from the fixed host properties dialog as shown in Figure 4-31. Here you are allowed to edit them as shown in Figure 4-32 on page 167. Figure 4-31 Profile fixed host properties166 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-32 Changing the profile fixed host propertiesFinally the changes are written back to the profile as shown in Figure 4-33.Figure 4-33 Amended fixed host propertiesWe can also look into the profile image and see which patches and applicationswere installed when the image was captured. So if you select Get moreinformation from the Profile Details screen, you see what is shown inFigure 4-34 on page 168. Here you see the Microsoft patches that are integratedto the image. Note that the patch names for example KB867282 are hyperlinks tothe Microsoft support Web site. In this case, to the following Microsoft Web site:http://support.microsoft.com/default.asxp?scid=kb;en_us;KB867282 Chapter 4. Installing pre-Vista systems 167
  • Further down the detail of the OS Image Analysis page, we can see the applications that were installed in the image. This is shown in Figure 4-35 on page 169. Figure 4-34 Profile image details from OS image analysis168 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-35 Details of applications integrated into the OS ImageNow that we changed the setup characteristics of the image and browsed theinstalled patch and application list, we can change the file and directory contentsof the image. This is great if we need to add or delete files or directories after wecapture the initial image—as it stops us from having to revisit the processes ofthe following: Machine cleanup Re running sysprep New profile creation or replacementThis feature thus saves time in the process of keeping up-to-date with smallchanges in a system base image. It also saves disk space as we can modify theoriginal image rather than creating a new one. The other benefit to this feature isthat it reduces the administrative effort in tracking large numbers of imagevariants.From the Profile Details as shown in Figure 4-21 on page 157, we select BrowseImage of Primary Partition. This then gives an explorer style interface to viewthe files in the image as seen in Figure 4-37 on page 170. Chapter 4. Installing pre-Vista systems 169
  • Figure 4-36 Launching the partition image explorer From the image explorer, we are able to create and delete folders as well as add and delete files from folders. Figure 4-37 Partition image explorer Now that we have created, viewed, and modified a cloned image, let us look at the process of handling unattended setup techniques.170 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 4.4 Creating an unattended profile for Windows 2000 We perform the following steps to create an unattended profile for Windows 2000: 1. Select Add a new profile, as shown in Figure 4-38. Figure 4-38 Creating a new OS profile 2. Decide what sort of profile we want to create. In Figure 4-39 on page 172 we create a profile for a Windows 2000 server. Chapter 4. Installing pre-Vista systems 171
  • Figure 4-39 Creating a WIndows 2000 system profile 3. Use an unattended set up process for this profile rather than create an image based profile. This is shown in Figure 4-40. Figure 4-40 Unattended Windows profile172 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 4. Define the partition size that will be used for the Windows 2000 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 an absolute size unless you are going to use 100% of the disk. You can see this in Figure 4-41.Figure 4-41 Specify the size of the target partition5. Specify the characteristics of the new disk partition, as in Figure 4-41. Chapter 4. Installing pre-Vista systems 173
  • Figure 4-42 Specify characteristics of new disk partition 6. Skip the step in Figure 4-43 because we do not want any more partitions at this time. Figure 4-43 Final disk partition display 7. Now that we defined the target partition of the machine, we need to identify where the Windows 2000 software is to be sourced.174 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Important: For this to work you need the Web Extensions installed on your workstation, making sure that it is configured to point to the Tivoli Provisioning Manager for OS Deployment server that will be hosting the new profiles. This is a special consideration in an environment where there are multiple Tivoli Provisioning Manager for OS Deployment servers. We recommend that you point your RbAgent configuration to the central server, as the profile images are replicated from here. Important: The configuration file can be changed manually and then the RbAgent service restarted. The configuration file does NOT support a host name rather than an IP address. See Program FilesCommon filesIBM Tivolirbagent.conf. In Figure 4-44 on page 176 we browse the local disk of the workstation running the browser interface to select the I386 directory of the Windows 2000 image that may be on CD or was copied locally to the workstation disk.4.4.1 Creating a slipstreamed OS image You may want to point to a version of the I386 directory that already has all of the current service packs slipstreamed into the base directory. The advantages of this mean the following for you: You do not have to install any service packs after the POS installation is complete. You do not have to move the base and the patched code to the target. This saves time for the installation process and saves space on the Tivoli Provisioning Manager for OS Deployment Server. We do not cover slipstreaming in details; instead, we provide a summary. Following is an example for Service Pack 4, where you need to perform the following steps: 1. Copy Windows 2000 i386 CD directory to disk with xcopy <cd>i386 <disk>win2000i386 /e. 2. Make a temp directory on local disk. md <disk>win2000sp4. 3. Copy service pack to the new directory with copy <cd>w2kso4_en.exe <disk>win2000sp4. 4. Extract the service pack while in the <disk>win2000sp4 directory with a w2kso4_en.exe /x. Chapter 4. Installing pre-Vista systems 175
  • 5. Slipstream the service pack into the base with the following: <disk>win2000sp4update.exe -s:<disk>win2000 At this point the Service Pack 4 is integrated into the base code. This process is pretty much the same for all Windows operating system variants.4.4.2 Selecting the Windows 2000 source tree Perform the following to select the Windows 2000 source tree: 1. Select the I386 path in the profile wizard, as shown in Figure 4-44. Figure 4-44 Windows 2000 When we are done, you will see the final path, as in Figure 4-45 on page 177.176 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-45 Selected path for I386 Windows 2000 directory2. When the files are delivered to the target machine, Tivoli Provisioning Manager for OS Deployment runs the appropriate setup command, which requires parameters to be passed as this is a silent installation. This includes the product key, so here we provide a default, as shown in Figure 4-46.Figure 4-46 Providing a Windows 2000 product key3. Who owns the target machine? What time zone does it operate in? What is the administrator password? Provide the answers as in Figure 4-47 on page 178. Chapter 4. Installing pre-Vista systems 177
  • Figure 4-47 Windows 2000 target machine details 4. There may be additional parameters that you want to pass to the unattended install process. You can manually create the contents of this file. Alternately, you can use the setupmgr utility that can be found in the deploy.cab file from the Windows 2000 distribution CD. We will use the Windows 2000 distribution CD here to make it easier to create a template for your custom requirements. Tip: These overrides for the sysprep process can apply to image and unattended operating system profiles.4.4.3 Building a custom sysprep.inf with setupmgr Perform the following to build a a custom sysprep.inf with setupmgr: 1. Start the setupmgr, as shown in Figure 4-48 on page 179.178 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-48 Starting setupmgr2. Generate an unattended install answers response file, as shown in Figure 4-49.Figure 4-49 Starting an unattended installation response file3. We are working with a Windows 2000 unattended installation response file. See Figure 4-50 on page 180. Chapter 4. Installing pre-Vista systems 179
  • Figure 4-50 Opting for a Windows 2000 unattended installation 4. We are working with Windows 2000 Server, as in Figure 4-51. Figure 4-51 setupmgr Windows 2000 Server 5. We need a fully unattended setup, as in Figure 4-52 on page 181.180 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-52 Fully automated installation6. Accept Windows licensing. See Figure 4-53.Figure 4-53 Accepting the Windows license7. Enter Name and Organization information, as shown in Figure 4-54 on page 182. Chapter 4. Installing pre-Vista systems 181
  • Figure 4-54 Specify name and organization 8. Assign names to computer, as shown in Figure 4-55. Figure 4-55 Assign computer names 9. We are now prompted to add details of the Administrator password of this machine.182 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-56 Specify 1 autologon to run custom script10.Specify typical network settings, as in Figure 4-57.Figure 4-57 Specify network settings11.Name the workgroup or domain. See Figure 4-58 on page 184. Chapter 4. Installing pre-Vista systems 183
  • Figure 4-58 Specify workgroup or domain Note: Note that there are specific functions in Tivoli Provisioning Manager for OS Deployment to add the new target to a domain. See 3.5.3, “Running rbagent from command line” on page 130 for more information. 12.Specify the time zone, as in Figure 4-59. Figure 4-59 Specify the time zone184 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • There are other options that are made available by setupmgr that you can specify but remember that we are just using this tool to help in generating the unattended.txt file, so for now we will skip the other options. What is important to know is how you are going to get a command to run after the operating system is installed. This script hook can be used for many purposes, for example: – Sending an e-mail notification – Sending an SMS text message – Updating a change control record – Restoring user personalities to the machine This same hook can also be used for the installation of software, but we recommend that there are better ways to do this that offer more control and flexibility, so we council against its use for this purpose. What we will do here is use this hook to start the restoration of all user personalities that were saved for a machine of this host name.Figure 4-60 Running a command after system installation When the setupmgr process finishes, we are left with a template that looks similar to Example 4-5 on page 186. Chapter 4. Installing pre-Vista systems 185
  • Example 4-5 unattended.txt file built by setupmgr ;SetupMgrTag [Data] AutoPartition=1 MsDosInitiated="0" UnattendedInstall="Yes" [Unattended] UnattendMode=FullUnattended OemSkipEula=Yes OemPreinstall=Yes [GuiUnattended] AdminPassword=xxxxxx AutoLogon=Yes AutoLogonCount=1 OEMSkipRegional=1 TimeZone=85 OemSkipWelcome=1 [GuiRunOnce] Command0 = "9.3.4.137Unattendedafter_install.cmd" [UserData] FullName=IBM OrgName=IBM ComputerName=* [LicenseFilePrintData] AutoMode=PerServer AutoUsers=5 [SetupMgr] DistFolder=C:win2000dist DistShare=win2000dist [Identification] JoinWorkgroup=WORKGROUP [SysPrepMassStorage] ?????????????????? [Networking] InstallDefaultComponents=Yes186 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • We now have a template that we can use; however, it is important to remember that Tivoli Provisioning Manager for OS Deployment will overwrite many user supplied options. So which ones should we use? We can use [SysPrepMassStorage] , [Components] and [GUIRunOnce], but note that [GuiRunOnce] should be run in conjunction with [GuiUnattended].4.5 Real world OS installation scenarios Our real world problem is to perform two operations as a part of the installation process. 1. Configure the Windows Firewall on the newly installed server. 2. Remove Windows Media® Player and Microsoft Messenger from the installation. You can achieve these results quickly and easily using Tivoli Provisioning Manager for OS Deployment.4.5.1 Configuring the Windows firewall To configure the Windows firewall during an unattended installation of the operating system, you normally have to provide an unattend.txt file as an argument to the setup command. We can simplify this process, by adding the unattend.txt arguments to the OS profile in Tivoli Provisioning Manager for OS Deployment. 1. In Figure 4-61 on page 188 we add the details to the profile. The parameters that we used as shown in Example 4-6 on page 188, enables the firewall but will admit connections from the local network on port 80, for example to allow the default HTTP web traffic. Chapter 4. Installing pre-Vista systems 187
  • Figure 4-61 Firewall configuration in unattend.txt 2. We also log packets that we drop and connection details into c:WindowsWindowsFirewall.log. Example 4-6 Firewall configuration sample [WindowsFirewall] Profiles=WindowsFirewall.ITSO Logfile = %WINDIR%WindowsFirewall.log LogDroppedPackets = 1 LogConnections = 1 ; ; enable standard ITSO profile ; [WindowsFirewall.ITSO] Type = 1 Mode = 1 Exceptions = 1 PortOpenings = WindowsFirewall.WebServer ; ; allow only port 80 TCP through firewall ; [WindowsFirewall.WebServer] Protocol = 6 Port = 80 Name = Web Server (TCP 80) Mode = 1 Scope = 1 3. After the Windows 2003 OS installation is complete, the firewall is enabled, as shown in Figure 4-62 on page 189. This is controlled by the mode operand in the profile.188 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-62 Firewall is enabled4. Look at the details of the firewall configuration to see that we successfully created a new profile called Web Server (TCP(80). Chapter 4. Installing pre-Vista systems 189
  • Figure 4-63 Firewall configuration profile 5. Look at the details of this configuration to see the firewall port settings. These are shown in Figure 4-64, where we only allow TCP connections on port 80 through the firewall. This behavior is controlled by the scope and port settings in the profile. Figure 4-64 Firewall port settings190 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 6. We can change the firewall configuration to only allow TCP connections through port 80 from the local subnet only, as shown in Figure 4-65. And this is controlled by the scope argument. Figure 4-65 Firewall configuration to only allow local subnet connections4.5.2 Removing imaged profile operating system features To remove features like Media Player or MSN® Messenger, we have to use the sysocmgr command. So how do we automate this process? Why would we need to do this? Well, read the following note, and consider that we may prefer to use Opera and iTunes as our default Web browser and media player software. This technique is suitable for cloned images where the donor machine was prepared with sysprep. Note: sysprep will re-enable some Microsoft components that were disabled in the donor image. In Example 4-7, a sysprep.inf extract automatically logs onto the OS with the Administrator account when the installation is complete. It then runs the sysocmgr command. Note that this operation only happens once, see AutoLogonCount. Example 4-7 sysprep.inf for adding and removing Windows components ; autologon the machine the first time to run add / remove programs [GuiUnattended] AdminPassword=itso05 AutoLogon=Yes AutoLogonCount=1 OEMSkipRegional=1 TimeZone=85 Chapter 4. Installing pre-Vista systems 191
  • OemSkipWelcome=1 ; run command to install or remove windows components [GuiRunOnce] "sysocmgr /i:%windir%infsysoc.inf /u:%windir%infunattend.txt /q /r /c /x" The arguments passed to sysocmgr include the components to be added to or removed from the OS, and they are defined as in Example 4-8. Example 4-8 sysocmgr parameters [Components] IEAccess = On OEAccess = Off WMPOCM = Off WMAccess = Off4.5.3 Removing unattended profile operating system features We will use this deployment problem as an example of how to copy some files to the target machine and then run a batch program. In our case, we want to copy the add_remove.cfg and add_remove.cmd to the install directory on the target computer and then run the add_remove.cmd command file. The contents of these files are shown in Example 4-9 and Example 4-10. When running these scripts, consider the security context in which they are run. If you need to run the command as the database instance owner, for example, then use the runas.exe command to set the context for the command. Example 4-9 Sample sysocmgr component arguments in add_remove.cfg [Components] IEAccess = On OEAccess = Off WMPOCM = Off WMAccess = Off The command you can run that reads the arguments in Example 4-9 is shown in Example 4-10. Example 4-10 Sample sysocmgr command in add_remove.cmd sysocmgr /i:%windir%infsysoc.inf /u:installadd_remove.cfg /q /r To achieve the addition and removal of Windows components after the installation is complete, Microsoft provides the sysocmgr command to perform192 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Add / Remove programs and components via CLI. For us, we will have to build aTivoli Provisioning Manager for OS Deployment software package. Softwarepackages are versatile items, but in this case, we are going to define a packagethat copies the contents of a directory to the target machine, and then executes acommand. Important: Do not be confused by the term software package. There is no function available within Tivoli Provisioning Manager for OS Deployment to explicitly install just software packages. The only item that can be explicitly installed with Tivoli Provisioning Manager for OS Deployment is a profile that contains either an unattended setup of an OS or, a clone of an OS. The only way that a software package can be installed is by association with an OS profile, meaning it is pulled by the installation of the OS.As a working model, consider Tivoli Provisioning Manager for OS Deployment asa part of a change management suite, such as the Tivoli Provisioning Managerthat installs the OS, and does basic configuration as in the Firewall configurationand the Windows component installation and removal. Use Tivoli ProvisioningManager to install patches, middleware, and applications on the new server or onthe workstation. Note: Tivoli Provisioning Manager V5.1 also has image management capabilities, and it uses Tivoli Provisioning Manager for OS Deployment Embedded Edition under the hood. This is discussed more in the section 8.2, “Tivoli Provisioning Manager V5.1” on page 399. Chapter 4. Installing pre-Vista systems 193
  • Figure 4-66 Starting the creation of a new software package 7. So, we use the supplied wizard to start the package creation as in Figure 4-66. The wizard then asks us details about the target OS, note that Vista targets are different here.194 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 8. The use of a software package is several fold, but in Figure 4-67, we define that we will run a custom action on the target computer. The custom action shown in Figure 4-68 is to copy down some files to the target and then execute a command.Figure 4-67 Defining a custom action on the target computer9. We identify where the source of the files is located in Figure 4-69 on page 196.Figure 4-68 Copy files and execute program on target computer Chapter 4. Installing pre-Vista systems 195
  • Figure 4-69 Identify the source of files for software package Important: Place nothing in the root directory of import; instead, place items under a sub directory. So identifying the source of a Software package, create the files under .../import/<software_package_directory> and not under .../import/. 10.In our case the software package files we need are located under the <Tivoli Provisioning Manager for OS Deployment_files_root>importAddRemove directory. So select this from the wizard, as shown in Figure 4-70. Figure 4-70 Select the import directory for the software package 11.We give the package a name, as you can see in Figure 4-71 on page 197. We identified the name of the package and its source; therefore, we can now move on to define its other attributes.196 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-71 Naming the software package12.Figure 4-72 identifies at which stage of the OS deployment that we want the execution of our commands to run. We have various choices here, as you can also see in Figure 4-73 on page 198.Figure 4-72 Software package attributes Why do we have so many choices? Well consider that we may have to set up the disk RAID configuration before the OS is deployed, which is catered for in the Before the OS is Installed Phase. Consider that you only want to install an Anti Virus update after your firewalls are fully configured and are operational. Your firewall configuration may take a reboot to activate, so in this case, link the installation of the Firewall Configuration to the When the OS is installed phase, and the Anti Virus update to the After one additional reboot. In this way, the reboot dependencies between the software packages are preserved.13.In our case, it is fine to install the software package when the OS in installed without a reboot. In Figure 4-72, we also identify the command to be executed, and the target path for the source directory. Chapter 4. Installing pre-Vista systems 197
  • Figure 4-73 Insertion phase for software package The package is then built, as shown in Figure 4-74. Figure 4-74 A successful software package creation 14.After successful creation, we can see the newly created software package, as shown in Figure 4-75. Figure 4-75 Browsing software packages4.6 Restoring the machine’s user personality settings We have another real world example of what we might want to do from within a software package. We showed an overview of using the scanstate.exe command supplied within the Microsoft User State Migration Tool Version 3 (USMT). This saves the details of a machines user settings to a storage area that is retained as a machine is rebuilt.198 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • We use the USMT loadstate.exe command to restore the user personality afterthe OS profile is deployed.This is USMT specific, but it allows us to explore techniques that are available tous with Tivoli Provisioning Manager for OS Deployment. The problem that wehave is that the user profile restore process, run by the loadstate.exe commandof USMT, must run in the context of an administrator. See the USMTdocumentation for further information. We could have each user restore theirown settings as they log onto the new machine, but we want all profiles restoredas the machine is built so that we are free to delete these saved profiles.The design that we chose uses Tivoli Provisioning Manager for OS Deploymentsoftware packages to copy files to the target machine and also to make registrychanges. The registry changes make the target computer logon on the first timeautomatically after the OS is installed, and then runs the USMT loadstate.execommand to restore all profiles on the machine.After the restore is completed, we then disable automatic logon and remove anyreference to the local administrator password.First let us look at the registry changes that we need to achieve this result inExample 4-11. These registry changes cause the Administrator to automaticallylogin with the associated password. We will show you how to embed this within aTivoli Provisioning Manager for OS Deployment software package.Example 4-11 Registry change to enable automatic logonWindows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrentVersionWinlogon]"AutoAdminLogon"="1""DefaultUserName"="Administrator""DefaultPassword"="notsure"1. We use the software package creation wizard as before, but this time we identify that we want to make a registry change as in Figure 4-76 on page 200 and Figure 4-77 on page 200. We then have to locate the .reg file that contains the appropriate registry file change. Tip: Create your registry changes using regedt32 or regedit, and then export them to a file. It is this .reg export file that is imported by the software package wizard. Chapter 4. Installing pre-Vista systems 199
  • Figure 4-76 Software package registry change wizard 2. The wizard continues and we specify that we want to perform a registry change, as seen in Figure 4-77. Figure 4-77 Making a registry change from within a software package 3. Figure 4-78 on page 201 locates the winlogon.reg exported registry file from regedt32 that will be imported into the software package. As the wizard continues, we see a confirmation of the registry key that will be changed by this file in Figure 4-79 on page 201.200 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-78 Choose our winlogon.reg registry file4. Confirm that you are updating the registry key that you expect, as shown in Figure 4-79.Figure 4-79 Confirm the registry key to update5. Choose where you want to stage the registry update file on the target machine, as shown in Figure 4-80.Figure 4-80 Choose staging location for registry update file. Chapter 4. Installing pre-Vista systems 201
  • At this point the target machine automatically logs on as Administrator after the OS is deployed and the machine is allowed to reboot. 6. Insert another registry change to identify the command to run when the logon is complete. Let us have a look at the details of this change in Example 4-12. This simply says - ‘run c:instaluserstaterestore.cmd as Administrator logs on’. In this way, we have the right user context to restore all profiles with the USMT loadstate.exe command. Example 4-12 Run the restore.cmd command as logon time Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce] "USMT"="C:installUserStaterestore.cmd" The restore.cmd command is sent down to the target machine by another software package bound to the same deployment scheme. This is not strictly necessary, as we could run the commands using UNC qualified commands from the save server on which we staged the scanstate.exe profiles. 7. So, as before, we create another software package, the highlights of which you can see in Figure 4-81. Figure 4-81 Identify the run key registry change export file 8. Next, we confirm that we want to update the registry key that we designed in our solution. See Figure 4-82 on page 203.202 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-82 Confirm that we are updating the runonce registry key on the target Now that we have our three software packages that deploy USMT and make our two required registry changes, let us look at how we control the sequencing of the software packages on the target machine. We could choose to run the loadstate.exe binary from USMT to perform the restore process from a UNC qualified drive. This means running the script shown in Example 4-13 on page 208. The restore.cmd script is run from the runonce registry key. This is important if the software packages have dependencies between themselves, or if there is a reboot required before an installation can start.9. From OS Deployment → Software Packages → Reorder Software you can see the sequencing of deployment that we created, as shown in Figure 4-83 on page 204, You can chose the sequence phase as you build the new software package, but let us see how this can be changed after they are built. The initial settings in Figure 4-83 on page 204 define that we will make the two registry changes and copy the USMT binaries to the target machine after the mini sysprep is done for a cloned installation, and after the setup for an unattended install. We will then reboot the machine and run our software package that adds and removes selected WIndows Components. This is a ‘drag and drop’ style interface, allowing for the creation and deletion of nodes in the deployment sequencing available from the palette at the bottom right of the interface. Chapter 4. Installing pre-Vista systems 203
  • Figure 4-83 Initial sequence of software package deployment 10.In our example, we have no need to execute the Customize Windows Components operation after a reboot operation, so we drag it into the ‘Stage 3’ phase of the deployment sequence, as shown in Figure 4-84 on page 205.204 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-84 Resequenced execution phasing11.Let us say that we require that one step only be executed after another is complete. How do we achieve this without an intervening reboot operation? To achieve this, we insert a new ‘Installation Stage’ in the deployment scheme. This is done, as in Figure 4-85 on page 206, using the palette at the bottom right of the interface. The name of the new sequence for us is ‘Post USMT’. Chapter 4. Installing pre-Vista systems 205
  • Figure 4-85 Insert a new installation step 12.You will see that the new stage is inserted at the end of the schema as in Figure 4-86 on page 207, which needs to be moved up the sequence using the ‘up’ and ‘down’ arrows in the tool palette at the bottom right of the interface.206 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-86 Newly inserted deployment stage13.When this operation is complete, you will see something similar to Figure 4-87 on page 208. You will also see that we have a reboot step that we do not need and that adds time to the deployment elapsed time. So once again using the tool palette, let us clean up this schema. We are performing this exercise to show you a way that you can manipulate the execution sequence of software packages, and how you might insert reboot operations where required. The sequence shown here does work for USMT profile restoration, but it is not the only sequence that can achieve the desired result. Chapter 4. Installing pre-Vista systems 207
  • Figure 4-87 Complete resequencing on new deployment stage Figure 4-88 on page 210 shows our completed software package deployment sequence schema. 14.There are several ways to get our desired result, we could for example have added a reboot at the end, but we chose to control the reboot from within the USMT restore script. Example 4-13 shows the complete contents. Example 4-13 User state migration restore script @rem Restore machine personality to XP machine @echo off set ZPATH="192.168.72.131UserMigration" set ZTMP=192.168.72.131UserMigrationlogs echo Starting the restore process > %ZTMP%%COMPUTERNAME%.log echo Environment variables .. >> %ZTMP%%COMPUTERNAME%.log set >> %ZTMP%%COMPUTERNAME%.log %SystemDrive% cd installUserState echo Check %COMPUTERNAME%_progress.log and %COMPUTERNAME%_loadstate.log for details >> %ZTMP%%COMPUTERNAME%.log208 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • %ZPATH%loadstate.exe192.168.72.131UserMigrationdata%COMPUTERNAME%/i:%ZPATH%miguser.xml /i:%ZPATH%migsys.xml /i:%ZPATH%migapp.xml /r:5/w:10 /progress:%ZTMP%%COMPUTERNAME%_progress.log /lac /v:13 /decrypt/key:"itso" /l:%ZTMP%%COMPUTERNAME%_loadstate.logecho Done restoring user settings >> %ZTMP%%COMPUTERNAME%.logecho Disabling the auto logon >> %ZTMP%%COMPUTERNAME%.logregedit /s disable.regecho Done >> %ZTMP%%COMPUTERNAME%.logecho Rebooting the machine .... >> %ZTMP%%COMPUTERNAME%.logshutdown -t 30 -r -c "TPM for OS Deployment will now reboot themachine. All deployment activity completed OK"15.Note that in the restore.cmd script we update the registry, as in Example 4-14. This is to stop the target machine from logging on automatically as the local administrator. Note that the action to run restore.cmd is removed from the runonce key after it is run a single time, so there is no explicit action to perform.Example 4-14 Disable automatic logonWindows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrentVersionWinlogon]"AutoAdminLogon"="0""DefaultPassword"="XXXXX" Figure 4-88 on page 210 shows the final software package sequence scheme that we used. Chapter 4. Installing pre-Vista systems 209
  • Figure 4-88 Completed software package sequence. All four software packages should now be bound to the deployment scheme called ‘Deployment’, as shown in Figure 4-89 on page 211. This is not an automatic action and should be done after the software packages are created and the new deployment scheme is made. The process of creating new deployment schemes and binding software packages to these schemes is covered in 5.4, “Deploying a Windows profile” on page 246.210 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 4-89 Bind software packages to the deployment scheme16.So, when we deploy a Cloned XP image to a new target using the deployment scheme named ‘Deployment’, we will restore all defined user settings, and also selectively add and remove Windows components according to our requirements with ZERO local interaction with the target machine. Chapter 4. Installing pre-Vista systems 211
  • 212 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 5 Chapter 5. Installing Vista systems This chapter provides step-by-step instructions for getting bare metal working for the Microsoft Vista operating system. It gives also some guidelines regarding the different possibilities you have between upgrading or replacing your existing pre-Vista systems. We cover the different possibilities regarding upgrading or replacing your pre-Vista environments, the two different ways of creating a Vista system profile, and the subsequent deployment of this profile on a target. Note: The Tivoli Provisioning Manager for OS Deployment term for an Operating System image is called a profile. This chapter contains the following sections: “Creating an unattended Windows Vista profile” on page 215 “Do I upgrade or replace?” on page 214 “Creating a cloning Windows Vista profile” on page 230 “Deploying a Windows profile” on page 246© Copyright IBM Corp. 2007. All rights reserved. 213
  • 5.1 Do I upgrade or replace? Microsoft offers different upgrade paths for licenses and software that are well documented at the following Web address: http://www.microsoft.com/windows/products/windowsvista/buyorupgrade/upg radepaths.mspx We do not deal with license upgrade paths here, instead, we look at upgrading the technology. The workstation options are summarized in Figure 5-1 on page 215. In the cases where people are upgrading from Windows NT, Windows 2000, or some variants of Windows XP, they will have to install the Vista OS from scratch using the techniques mentioned in the chapters that follow. This process typically involves the following: 1. Saving user files and settings of the donor machine. 2. Assessing whether the machine is ready for an upgrade. 3. Upgrading the machine to Vista. 4. Restoring the user files and settings to the new operating system. Only in the case where the original machine was Windows XP Home or Windows XP Professional can the OS be upgraded in place.214 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-1 Technical upgrade options to Windows Vista Upgrading the operating system using an unattended profile exploits the native function of the unattended installation process to migrate user settings and preserve user files.5.2 Creating an unattended Windows Vista profile The main purpose of Tivoli Provisioning Manager for OS Deployment is to deploy an operating system on client computers by replicating a reference system. However, unattended installation of the operating system is also possible. If you decide to create an unattended Windows Vista installation profile, Tivoli Provisioning Manager for OS Deployment does not replicate a reference system. You will have to give the Tivoli Provisioning Manager for OS Deployment server all of the details that it would need to walk through an installation of a Windows Vista operating system. Note: Unattended installation effectively means native installation. Chapter 5. Installing Vista systems 215
  • All of the installation tasks are executed from the Tivoli Provisioning Manager for OS Deployment server. Creating unattended installation profiles is easier than cloning profiles. However, Tivoli Provisioning Manager for OS Deployments native mode of operation is centered around cloning-mode system profiles because this method of deployment is faster than unattended installation. When deploying computers on a large scale, unattended installation is not possible. We cover the Windows Vista profile in the following two steps: Creating the Profile Creating the WinPE software package5.2.1 Creating the Profile Use the following steps to create an unattended Windows Vista profile: 1. Launch the Tivoli Provisioning Manager for OS Deployment Web console (Figure 5-2 on page 217). It can be done in the following two different ways: a. Remotely from your Internet browser using the syntax http://TPM server name:8080. b. Locally from your from Tivoli Provisioning Manager for OS Deployment server: Start → Programs → IBM Tivoli Provisioning Manager → Web console. If you are connecting to the Web console for the first time, take a few minutes to read important information by clicking the First time console user link as shown in Figure 5-2 on page 217.216 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-2 Launch the Tivoli Provisioning Web console2. Log on with the User ID and Password that you specified during the Tivoli Provisioning Manager for OS Deployment installation—if you have not yet created another User ID.3. Click the OS Deployment menu item, and select Profiles.4. Click the New Profile button at the bottom of the screen. You will get a screen as shown in Figure 5-3 on page 218. A wizard will guide you through the different steps of creating a profile. We are going to explain all these steps in detail. Chapter 5. Installing Vista systems 217
  • Figure 5-3 Create a new System profile 5. Select the type of profile to be created, an Unattended setup (scripted install) in our case as shown in Figure 5-4, and click Next. Figure 5-4 Choose the deployment mode 6. Select the deployment mode, namely A Windows Vista system profile, in our case as shown in Figure 5-5 on page 219, and then click Next.218 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-5 Choose the operating system type7. The wizard will ask you to specify the folder where the Windows setup files are located as shown in Figure 5-6. We copied all of the CD content on disk into the C:tempCode-Vista directory. Click Next.Figure 5-6 Specifying where the Windows Vista setup files are located8. The wizard indicates which version was found in the directory you just provided. Click Next. See Figure 5-7 on page 220. Chapter 5. Installing Vista systems 219
  • Figure 5-7 Version found 9. Specify a size for the Windows Vista partition. This can be done as a fixed MB size or as a percentage of the total disk space. In Figure 5-8, we select a percentage. Figure 5-8 Partition size specification220 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 10.Figure 5-9 shows that you must select parameters for this new partition. Specify the format as FAT16, FAT 32, or NTFS, as well as the size, and click Next. Tip: If you choose a value of 100%, you can possibly restore your profile on any kind of hard disk size.Figure 5-9 Select parameters for the partition11.Click the radio button next to the partition you want to use as the target partition for Windows to complete the partition layout process. See Figure 5-10 on page 222. Chapter 5. Installing Vista systems 221
  • Figure 5-10 Select the partition 12.For a later fully unattended installation, you must enter a valid Windows Product Key as shown in Figure 5-11, and click Next. Figure 5-11 Windows Product Key 13.You can configure some fixed properties, such as registered owner and time zone as shown in Figure 5-12 on page 223. Click Next.222 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-12 Fixed properties14.The next screen (Figure 5-13) allows you to specify a custom configuration file with custom settings that you can use in your system profile. Tivoli Provisioning Manager for OS Deployment automatically patches this file with host-specific settings. If you do not need it, click Next to skip this step.Figure 5-13 Custom set up configuration file15.In Figure 5-14 on page 224 you are asked to enter a description for your system profile, such as Windows Vista Enterprise. Chapter 5. Installing Vista systems 223
  • Figure 5-14 System profile description 16.Click Next to start the creation of the unattended set up profile. It might take a few moments for Tivoli Provisioning Manager for OS Deployment to create the archive containing all the files required for Windows installation (Figure 5-15). Figure 5-15 Profile packaging in process 17.Figure 5-16 on page 225 displays a message indicating that the system profile was successfully created. A WinPE software package is required to deploy a Vista profile. Click the here link in order to switch directly in the software package wizard as shown in Figure 5-16 on page 225. You do not224 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • have to worry because if you already clicked Finish, you can still create this package from the software packages link in your Web console as described in section 5.2.2, “Creating the WinPE software package” on page 225. Figure 5-16 Profile successfully created5.2.2 Creating the WinPE software package If you just created your Vista profile, you are probably coming just from the step before as described in Figure 5-16. In such a case, just continue with this section and go through the next steps described in the following pages. In the opposite case, start the software package wizard from OS Deployment → Software packages, and select New software → Windows Vista → A custom action on the target computer → A WinPE 2.0 Ramdisk image. Continue through the screens to the end of this section. Chapter 5. Installing Vista systems 225
  • 18.Read the information in the following note about WinPE, and click Next, as shown in Figure 5-17. Note: Microsoft Windows Preinstallation Environment (Windows PE) 2.0 provides preparation and installation tools for the Microsoft Windows Vista operating system. Microsoft WinPE is a minimal OS, based on the Windows XP kernel, that replaces MS-DOS® during the initial OS installation stages beginning with Vista OS, which is known as Longhorn. It provides a GUI environment during the entire installation instead of the old text-based screen prompts that are common during the initial set up of earlier Windows installations. Figure 5-17 Information about WinPE 19.Specify where the Vista source code is located, and then click Next as shown in Figure 5-18 on page 227. This screen shows different possibilities. Most of them require the Web Interface Extension to be installed.226 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-18 Vista code location20.A default description is provided by the product as shown in Figure 5-19. You can modify it to fit your naming conventions, and then click Next.Figure 5-19 Description of the WinPE software package21.A default name is also provided for your package, as it will be stored on the server side. We modified it with a more meaningful name as shown in Figure 5-20 on page 228. Click Next. Chapter 5. Installing Vista systems 227
  • Figure 5-20 Name the software package The software package generation starts. It should take a few minutes depending on your computer speed. Figure 5-21 WinPE package generation 22.At the generation completion, a screen appears that explains how to bind this package to individual targets, as shown in Figure 5-22 on page 229. Click Finish.228 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-22 Successful creation of the software package23.Go to OS Deployment → Software packages to see your new package as shown in Figure 5-23.Figure 5-23 Control of the software package creation24.To get a detailed description of this package, double-click it. You will get a screen similar to Figure 5-24 on page 230. Chapter 5. Installing Vista systems 229
  • Figure 5-24 Detailed description of the software package 25.At this point, you created an unattended Vista profile and a specific WinPE software package requested for deployment of a Vista operating system. Before you can deploy this new image on a target, you must configure it properly. Please refer to “Configuring the System profile” on page 241. This section is common to the unattended and cloning installations.5.3 Creating a cloning Windows Vista profile Tivoli Provisioning Manager for OS Deployments native mode of operation is centered around cloning-mode system profiles. Deployment through the cloning method is faster than an unattended installation. The cloning-mode system profiles are more efficient for deployment than the unattended installation system profiles. Cloning a Vista profile consists of taking an image of a computer containing a running and configured version of Windows Vista. Next, run the profile creation from the system to be cloned using a Tivoli Provisioning Manager for OS Deployment Administrative Toolkit that is distributed to the clone host by the Tivoli Provisioning Manager for OS Deployment server. This section guides you through the three main steps to create a system profile based on the Windows Vista Client. Preparing the System230 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Capturing the System Image Configuring the System profile5.3.1 Preparing the system Tivoli Provisioning Manager for OS Deployment does not perform any cleanup on your machine. Before you can clone your Vista machine, you need to make sure that the system is as clean as possible before you start. Typically this means that you need to do the following: Empty the machine recycle bin. Delete the Internet cached files—cookies and history. Delete your temporary directories and files. Disconnect any network shares and remote printers. Also be aware that the account named Administrator needs to exist in the machine to be cloned; however, Vista disables it as a part of the deployment process, so have an additional account belonging to the Administrator group in order for the deployment process to work properly. Be ready to run a Microsoft utility called Sysprep on this system that will be considered as your reference OS. Windows Vista only allows you to run Sysprep on the operating system three times. After that, the Sysprep tool refuses to start, so always start from your original reference image. Microsoft Sysprep for Windows Vista is available on every installed Vista OS. The following steps allow you to start the Sysprep utility. 1. Close all of the open applications and run the Sysprep executable file located in the c:windowssystem32sysprep directory. Windows Vista asks for your permission to continue. Click Continue, as shown in Figure 5-25. Figure 5-25 User Account Control Chapter 5. Installing Vista systems 231
  • 2. In the System Preparation Tool pop-up, select the following options, as shown in Figure 5-26: a. Select Enter System Audit Mode from the System Cleanup action drop-down menu. b. Select the Generalize check box. c. Select Shutdown from the Shutdown Options menu. d. Click OK. The Vista system should shut down automatically and become ready to capture the image. Figure 5-26 System Preparation5.3.2 Capturing the System Image 1. Start your reference Windows Vista system and boot it to the network so that the Tivoli Provisioning Manager for OS Deployment server can discover it and manage it. When you boot your computer, the BIOS looks for the boot priority in the configuration. If it is configured to boot first on disk, it must be overridden simply by pressing the F12 or ESC keys at the beginning of the boot sequence. After the Tivoli Provisioning Manager for OS Deployment server catches the system, a screen appears on the Vista machine, as described in Figure 5-27 on page 233.232 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-27 Boot in the network2. After the Tivoli Provisioning Manager for OS Deployment server identifies the computer and writes a basic hardware scan data into the Tivoli Provisioning Manager for OS Deployment database, the guest will display a screen as shown in Figure 5-28. Note: If you have several PXE servers in your architecture, you must verify if the IP address displayed in the upper right part of the screen matches with the PXE server you expect to use.Figure 5-28 Guest identification3. Log on to your Tivoli Provisioning Manager for OS Deployment Web console from a Web browser using the syntax http://TPM server name:8080 or from your from Tivoli Provisioning Manager for OS Deployment server: Start → Programs → IBM Tivoli Provisioning Manager → Web console. Chapter 5. Installing Vista systems 233
  • 4. Select OS Deployment and then Host Monitor in the left pane as shown in Figure 5-29. Figure 5-29 Access to the targets 5. Select the newly discovered system in the Host Monitor view, and choose Start admin toolkit from the left margin menu. Alternately, right-click the discovered host and select Start admin toolkit from the pop-up menu, as shown in Figure 5-30. Figure 5-30 Launching the admin toolkit 6. The following screen is displayed (Figure 5-31 on page 235). If you want to bind the Administrator Toolkit to the template server, you can do so by checking the Bind the Administrator Toolkit to selected hosts option. This has the effect of causing the admin toolkit to launch on the Tivoli Provisioning Manager for OS Deployment client when ever the network boots from the234 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Tivoli Provisioning Manager for OS Deployment server. This might be useful if you need to perform extra work on the template server; otherwise, download the admin toolkit to the client each time you need to adjust the profile. Deselect the option Try to wake-up hosts currently powered off, and click OK.Figure 5-31 Start Admin Toolkit7. Go back to your reference Vista machine. You should see a screen as shown in Figure 5-32 on page 236. Select the Make a new image icon. Other possibilities are available from this screen to modify the disk partition or Restore an image that was previously saved. Chapter 5. Installing Vista systems 235
  • Figure 5-32 Image creation 8. The Image Creation menu is then displayed (Figure 5-33). Click the icon to select the Create a System Profile. Figure 5-33 System profile creation 9. In the Description field, press the Esc key to erase its content. Then type Windows Vista, and click Next. (Figure 5-34 on page 237). You can type a description of your profile in the Comment field.236 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-34 Name your profile10.The Model name field is automatically populated. For the purpose in this publication, you can see that we are working with VMWare tools. Tivoli Provisioning Manager for OS Deployment automatically populated the Model name. You can leave it as is if you want to deploy the profile only on this particular model. You can also erase the model name if the image has to be installed on a different kind of machine without any verifications. Click Next, as shown in Figure 5-35.Figure 5-35 Model name specification11.Review your profile parameters, and click Next as shown in Figure 5-36 on page 238. We modified the Model name to deploy only the profile on a specific model. Chapter 5. Installing Vista systems 237
  • Figure 5-36 Verification 12.Building the image will take several minutes and depends on the speed of your network, the size of the image, and if any similar images were already created. See Figure 5-37. Figure 5-37 Image building 13.If you look at the bottom of the screen, you will see a Tivoli icon as shown in Figure 5-38 on page 239. This icon hides some very useful features. You can launch a console locally to check the different steps for image cloning.238 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • All these detailed messages can also be uploaded on the server by selecting the Upload console option. This log can be useful for analysis purposes. You can access the log from your Web console. a. Go to OS Deployment → Host Monitor → Host details. b. Click Logs tab, and select the log corresponding to your image cloning. c. The download option gives you the option of saving this log where you want.Figure 5-38 Checking the image building14.. Verify the successful creation of your image, as shown in Figure 5-39. Click Ok.Figure 5-39 Successful creation of an image15..Click Exit Administrator Toolkit, as shown in Figure 5-40 on page 240. Chapter 5. Installing Vista systems 239
  • Figure 5-40 Main functions menu 16.To exit from the Administrator Toolkit, select one of the options that is the most convenient for you. Figure 5-41 shows that you can either turn off the computer or reboot it with the possibility to enforce a boot on Vista. Figure 5-41 Exit menu 17.Return to your Tivoli Provisioning Manager for OS Deployment Web console, and select OS Deployment → Host Monitor as shown in Figure 5-42 on page 241. You will see a green color for your host, which means that your OS capture was successfully completed. Different colors can be seen depending on the activity.240 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-42 OS capture is successfully completed5.3.3 Configuring the System profile A profile needs to be configured before it can be deployed on a target. This is true for both the Unattended and the Cloning profiles. 1. Select the profile you want to configure, and click the Configure link, as indicated in Figure 5-43. Chapter 5. Installing Vista systems 241
  • Figure 5-43 Profile selection for configuration242 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 2. Select Edit link in the Fixed host properties section as shown in Figure 5-44.Figure 5-44 Fixed host properties access3. You can enter different regular expressions or provide variable substitution here. For instance, the [IP] variable in the Hostname field automatically inserts the machine assigned IP address. You can also concatenate a fixed field with these variables. Examples: Vista-[IP] could give Vista-9.1.2.3 You will see in the Tivoli Provisioning Manager for Operating System Deployment Guide (Fix Pack 1), SC32-2582 under "Setting up profile configurations and fixed common parameters" that you can also use the [MAC], [SN], [AT] keywords for Mac address, Serial Number, and Asset Tag to identify your target. A range extension is also supported by each of these keywords. Moreover, if you need more flexibility, you can create different kinds of associations through a feature available in the Tivoli Provisioning Manager for OS Deployment. To achieve this, go to OS Deployment → Host Monitor Chapter 5. Installing Vista systems 243
  • and launch the Export hosts feature at the bottom of the screen to export your existing hosts definitions in a .csv file. You can use this file as a model to create your own .csv file, and then import a list of new hosts using the Import hosts function. An example is to create a list with only the SN and the IP fields. In our example, we selected the following parameters, as in Figure 5-45, and clicked OK. Hostname: Vista-[IP] TCP/IP mode: Use a dynamic IP address (DHCP) Figure 5-45 Fixed Host Properties information 4. Select the Edit link from the Windows-specific section. 5. Enter your product key, Network type, and Administrator name. Click OK as shown in Figure 5-45. Here we also provided values for the screen resolution.244 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-46 Fixed Windows settings6. Select Edit link from the Fixed user properties section. The Figure 5-46 gives you an example of how the form can be filled. There are also four freely configurable user categories that can be used to store information regarding the user (such as position, department, and location), and that can be used in the software matching mechanism (automatic binding rules). Click Ok. Chapter 5. Installing Vista systems 245
  • Figure 5-47 Fixed user properties5.4 Deploying a Windows profile 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 a deployment scheme. The following sections describes how to create a deployment scheme, how to register new target hosts in your Tivoli Provisioning Manager for OS Deployment server database, and also explains an example of Vista deployment.5.4.1 Creating a deployment scheme 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. 1. Select OS Deployment → Deployment schemes in the left pane of the Window, as shown in Figure 5-48 on page 247.246 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-48 Creating/Browsing the deployment schemes2. Select New scheme at the bottom left side, and type a name for this new scheme. Click Next as shown in Figure 5-49 on page 248. Chapter 5. Installing Vista systems 247
  • Figure 5-49 Naming your deployment scheme 3. Even if we are deploying an unattended profile, we can still ask to edit the host-specific parameters (such as host name, user name, and so on) interactively at the time of the deployment. Indeed, the typical use of Tivoli Provisioning Manager for OS Deployment involves configuring the target hosts to boot from disk first; however, occasionally, you will press F12 at start up, to boot from the network when a deployment is needed. Select the Always edit host-specific parameters interactively option to avoid repeated deployments of the OS on your machine that will happen without any user option to halt this looping process. If you do not want to follow the typical way, and you prefer configuring your hosts to always boot first from the network, then you must activate the Boot on hard-disk option in the Boot settings of your host definition after the deployment is completed. If this is not done, these hosts will return to the screen prompting you to deploy the image again—giving us a loop in the process. In this case, you should choose the Never edit parameters, run the deployment unattended option. This then gives you a zero touch installation scenario. Select Always edit host-specific parameters interactively, and then click Next as shown in Figure 5-50 on page 249. Note: For more information on host boot settings, refer to 7.5, “Understanding the host boot settings” on page 345.248 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-50 Unattended deployment4. Now, you can get Tivoli Provisioning Manager for OS Deployment to do Hardware and Software inventory on the target. Different possibilities are given to decide when it must be performed and what level of information you want to collect. See Figure 5-51 for an example, and click Next.Figure 5-51 Hardware and Software inventory parameters Chapter 5. Installing Vista systems 249
  • 5. You can also decide whether few tasks must be done by the user and manage the state of your target at the end of the deployment. Figure 5-52 shows the default options. Click Next. Figure 5-52 Control the target after deployment 6. Tivoli Provisioning Manager for OS Deployment allows you to control the network bandwidth when you deploy your profiles as shown in Figure 5-53 on page 251. The Tivoli Provisioning Manager for Operating System Deployment Guide (Fix Pack 1), SC32-2582 manual gives you all the details about these options under the "Customizing deployment schemes" chapter.250 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-53 Networking mode7. The On site deployment features screen gives you the ability to enable the Redeployment feature of Tivoli Provisioning Manager for OS Deployment on your target. This feature is described in detail in Chapter 10, “Redeployment and self-healing feature” on page 419. In our example, we leave the option unchecked. Click Next, as in Figure 5-54.Figure 5-54 Redeployment feature implementation Chapter 5. Installing Vista systems 251
  • 8. You will get the last screen saying your deployment scheme is now set. Click Finish to close the wizard. See Figure 5-55. Figure 5-55 Click Finish 9. You can still verify your new deployment scheme (do not forget to select it in the list) and eventually edit parameters before using it in a deployment. If you want to, go to OS Deployment → Deployment schemes in the left pane of your console as shown in Figure 5-56 on page 253.252 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-56 View and modify Deployment schemes5.4.2 Registering hosts in Tivoli Provisioning Manager for OSDeployment server If your target is already known to Tivoli Provisioning Manager for OS Deployment server, you can skip this section, and go directly to the 5.4.4, “Deploying a Vista profile” on page 257. Tivoli Provisioning Manager for OS Deployment offers the following three different techniques to register new hosts (targets) in your server database: Boot the target on the network to automatically register it. To boot on the network, press the F12 or ESC keys at the beginning of the boot sequence. Manually register a host or a range of hosts from the Web console. Go to OS Deployment → Host Monitor and click Register new hosts at the bottom of the page to get a screen as shown in Figure 5-57 on page 254. Chapter 5. Installing Vista systems 253
  • You can specify either the MAC address, IP address, Serial number, UUID, or any combination of them. Figure 5-57 Registering a host manually Tip: When can it be useful to manually register a new host? This may arise when automatic registration does not work with some type of hardware. Some older versions cannot support some new features such as the Enhanced PXE feature. You can disable this feature after you manually register your new host and before you start the deployment. Go to OS Deployment → Host Monitor, select your host in the Host Monitor list, view host details, edit Boot Settings, and check the Disable enhanced PXE access option. To register hosts as IP range, click the appropriate link, as shown in Figure 5-57. Specify a starting address and a Count. Click Register. You will get nine new hosts registered from IP address 9.3.4.120 to 9.3.4.128. Figure 5-58 Registering hosts as IP range Import a list of hosts from a .csv file.254 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • To start with, you need to know the format of the file recognized by Tivoli Provisioning Manager for OS Deployment. Go to OS Deployment → Host Monitor and click Export hosts at the bottom of the page. You will be allowed to save a hostexport.csv file where you want to save. Analyze this file as a template before creating your own .csv file. To import it, click Import hosts at the bottom of the page. Tip: When can it be useful to import a list? You can parse the hostexport.csv file with a script and create a new .csv to industrialize your deployments by, for instance, specifying an association between Serial Numbers and Host names.5.4.3 Creating a new user through a software package At the end of the deployment of the Vista profile on your new target, you can expect to have an additional local user created with the standard Administrator account. You can manage this requirement by creating a software package before proceeding to the deployment phase. 1. Go to OS Deployment → Software packages → new software. 2. Check the following options in the Software Package Wizard: – Windows Vista – A custom action on the target computer – A configuration change to perform on the target computer (a registry patch, a command to execute) – Execute a single command 3. Enter a name and a description for your new software package as shown in Figure 5-59 on page 256. Chapter 5. Installing Vista systems 255
  • Figure 5-59 User creation through a software package 4. Specify when you want to execute your software package, and type the exact command line to create your local user as shown in Figure 5-60. Click Next. You will get a screen saying that your software package was successfully created. Figure 5-60 User creation command line 5. Click Finish to exit the software wizard. Now, you can see your new software package in the Software packages list, as shown in Figure 5-61 on page 257.256 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-61 New software package created 6. In order to get this user created at the end of the Vista profile deployment, just remember that we have to bind this new software package during the next phase, which is described in “Deploying a Vista profile” on page 257. Important: The method previously discussed is one way of creating a user in order to fulfill this Vista requirement. There is also an alternative way to create a user with the Tivoli Provisioning Manager for OS Deployment. To use this method, do the following: Open a Vista profile, and then open the associated configuration page. You will see an option called "Create a local account for the user". If you set this option, a user is automatically created, using the Full Name field as the user name.5.4.4 Deploying a Vista profile To be ready for use by an end-user, a computer must have the operating system installed at the end of the deployment as well as the required applications and drivers. Deployment is a process of installing a profile on a computer. When the deployment is complete, the operating system is installed and ready to be used by the user defined for this host in the database. Tivoli Provisioning Manager for OS Deployment allows you to install the required application packages and drivers as part of the initial deployment. Refer to 7.2, “Software package rules and bindings” on page 315 and 7.4, “Device driver injection” on page 332 for more information about those topics. In this section we review the deployment of a Vista profile. Chapter 5. Installing Vista systems 257
  • We use the automatic registration technique of a new target in the following example. 1. To register your new target host, you first need to boot it on the network, by pressing the F12 or ESC keys just at the beginning of the boot sequence. 2. A new entry appears in the Host Monitor list. Select it, right-click, and select Deploy now from the submenu, as shown in Figure 5-62. Figure 5-62 Start the deployment from the Web console 3. A screen similar to Figure 5-63 on page 259 will appear. a. Select the Deployment scheme that you created earlier in the section “Creating a deployment scheme” on page 246. b. Select the profile you want to deploy on the target. c. Remember that we also want to install a WinPE software package and to create a customer user on this target. Click the Edit manual software binding link. A screen similar to Figure 5-64 on page 260 appears. You can refer to the section “Software package rules and bindings” on page 315 for more information and alternative ways for the software package binding process. d. Select the software packages you want to deploy along with the OS.258 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • e. Click Ok to return to the Start deployment screen. f. Click Ok to start the deployment.Figure 5-63 Select the deployment scheme, profile, and software packages Chapter 5. Installing Vista systems 259
  • Figure 5-64 Select the software packages to deploy 4. Now, you can see a screen as shown in Figure 5-65 on page 261 on your target computer. It will take several minutes and several boots before you see Vista running on your target. Sometimes this may take a little more time. You can access the same features here as previously described during the cloning profile creation in Figure 5-38 on page 239. Remember the following features: Click the red Tivoli icon at the bottom-left corner of the screen. You can launch a console locally to see what is happening after selecting the Show Console option in the menu. This does not affect the deployment process. You can also upload all this detailed information on the server by selecting the Upload console option. You will then have the ability to access the log from your Web console, a. Go to OS Deployment → Host Monitor → Host details. b. Click the Logs tab, and select the log corresponding to your image deployment. c. The download option allows you to save this log in the location you want to save it.260 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 5-65 Unattended Vista profile deployment Chapter 5. Installing Vista systems 261
  • 262 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 6 Chapter 6. Installing Linux systems In this chapter we describe how to get a bare metal machine work with a Linux operating system using one of the main features of Tivoli Provisioning Manager for OS Deployment: the deployment of a profile. We also create software packages that are automatically installed on the target computer after the deployment process. We assume that you have a working Tivoli Provisioning Manager for OS Deployment environment. For information on how to install Tivoli Provisioning Manager for OS Deployment, you can refer to Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1, SG24-7397. This chapter has the following sections: “Introduction and general requirements” on page 264 “Creating an unattended setup profile” on page 265 “Creating software packages” on page 275 “The deployment process” on page 286 “Cloning a machine” on page 292 “Deploying the cloned profile” on page 299© Copyright IBM Corp. 2007. All rights reserved. 263
  • 6.1 Introduction and general requirements 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 Linux profile with some software packages that will be deployed on a bare metal machine. Then, we describe the cloning process of a Linux machine and the customizing of the captured image. According to the Tivoli Provisioning Manager for Operating System Deployment Guide (Fix Pack 1), SC32-2582, the UNIX/Linux supported operating systems for deployments are as follows: Linux Fedora Core: Fedora3, Fedora4 (cloning + setup) RedHat Enterprise Linux (RHEL): versions 3, 4 (cloning + setup) SuSE Linux Professional: versions 8, 9 (cloning + setup) SuSE Linux Enterprise Server (SLES): version 9 (cloning + setup) Debian GNU-Linux 3.1 (Sarge) (cloning ONLY) Sun Solaris (Sparc): versions 8, 9, 10 (cloning + setup) For both the unattended set up and the cloning deployments, we use Red Hat Enterprise Linux 4, AS Update 3. In terms of Tivoli Provisioning Manager for OS Deployment, we will do the following: Create an unattended Linux installation profile using RHEL 4 installation CDs. Clone a machine having the RHEL 4 operating system. For a target machine, the official requirements are as follows: PXE-compliant bootrom, either version 2.00 and above Minimal CPU: PentiumR type level Minimal RAM memory: 128 MB Video Electronics Standards 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 headless machines.264 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Either a traditional Advanced Technology Attachment (ATA) drive with Ultra™ Direct Memory Access (DMA) support if speed is required or a BIOS-supported hard drive. Desktop Management Interface (DMI) support for collecting hardware information, such as model and serial number. To meet these requirements, we use machines equipped with at least 8 GB of disk space since the Linux installation and the hidden partition used by Tivoli Provisioning Manager for OS Deployment during the deploy may have problems with hard disk of lower capacity.6.2 Creating an unattended setup profile In order to create a new unattended profile, perform the following steps: 1. Select OS Deployment → Profiles, and then choose the New Profile item. The Web Interface Extension component is needed for this procedure. If you have not installed this in your system you will get the message shown in Figure 6-1. Figure 6-1 The Web interface extension is needed when creating new profiles 2. If the Web interface extension is running on your machine, you can proceed to creating a new profile. Configure the profile to do the following: – Be a Linux unattended setup profile – Set correctly the partitions in order to have the following: • A swap partition of 1GB • A boot partition of 256 MB • A root partition on the remaining disk space – Set KDE as the desktop environment Chapter 6. Installing Linux systems 265
  • – Install some basic software (RPMs provided in the installation CDs) – Set correctly the language and regional settings 3. The first window of the wizard asks you the operating system that will be contained in the profile. Select the Linux system profile option as shown in Figure 6-2. Figure 6-2 Choosing the OS on the Profile Wizard 4. In the next Profile Wizard window, choose the Unattended setup, as shown in Figure 6-3 on page 267. 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 these parameters that are needed to install an operating system on a bare metal machine are automatically provided to the process without any user intervention at a later time. Moreover, Tivoli Provisioning Manager for OS Deployment allows users to modify these configuration parameters after the completion of the wizard.266 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-3 Choosing the Unattended setup option in the Profile Wizard5. As we are installing the system on a bare metal machine, we need to configure the partition layout. We will accept the default configuration, which is created in the following order: – A SWAP partition of 1024 MB. – A separate partition where the “/boot” filesystem is mounted of 256 MB. – A partition (formatted as ext3) on the remaining disk size where the root file system is mounted. We suggest allocating 100% of the remaining disk size to the root file system as shown in Figure 6-4 on page 268 and setting it in the last position of the disk in order to avoid insufficient space problems. This failure may arise both by the Linux unattended installation or by the deployment process. We experienced it when setting the root partition to a fixed 4 GB size. Allocating all the disk space for the last root partition should prevent both the problems since the following applies: – The Linux installation has all the available disk blocks for copying binaries (8GB in our case). – The deployment process has all the available disk blocks for temporary storage (since it uses the free space remaining in the last partition). Chapter 6. Installing Linux systems 267
  • Figure 6-4 Setting the partition layout in the Profile Wizard 6. The partition layout can be subsequently modified by accessing the properties of the specific configuration. Figure 6-5 shows how the editor of the partition layout appears from the Web console. Figure 6-5 Partition layout editor for the configuration created 7. The next steps (see Figure 6-6 on page 269) ask you to select the path where the installation CDs/DVDs can be accessed. Since all the deployment steps do not require you to manually insert the needed media on the target machine, all the data is required to be loaded on the server at this step.268 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-6 Select source media in the Profile Wizard8. Figure 6-7 on page 270 shows that the operating system we provided in the installation CDs was recognized and we are prompted for the base configuration to use. Here, we choose the KDE option. Chapter 6. Installing Linux systems 269
  • Figure 6-7 Choosing the base configuration in the Profile Wizard 9. In the last two steps of the profile wizard, we can do the following: – Select which of the software provided with the installation CDs is added to the machine. – Set the language and regional settings. Figure 6-8 on page 271 and Figure 6-9 on page 271 shows our settings.270 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-8 Additional software installation in the Profile WizardFigure 6-9 Language and regional settings in the Profile Wizard10.Since we are not using advanced settings, we will leave the File field empty as shown in Figure 6-10 on page 272. Chapter 6. Installing Linux systems 271
  • Figure 6-10 Advanced configuration in the Profile Wizard 11.Finally, insert the name of the profile with a descriptive comment. Take care to describe the complete name of the operating system we used, Red Hat Enterprise Linux 4 AS, Update 3 as shown in Figure 6-11 on page 273.272 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-11 Inserting name and description of the profile in the Profile Wizard12.After completing all the configuration steps, the server will load all the data and creates the profile in its database. Figure 6-12 on page 274 shows that you may be prompted to insert different installation CDs. Chapter 6. Installing Linux systems 273
  • Figure 6-12 Required installation media in the Profile Wizard 13.If all the steps are performed correctly, you will receive a message stating that the profile was successfully created as shown in Figure 6-13. Figure 6-13 Outcome message in the Profile Wizard274 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 14.After completing the Profile Wizard, you can also use the Web console to modify the recently specified settings. To perform this operation, navigate through your profiles list (OS Deployment → Profiles), and edit the specific binded configuration. Figure 6-14 Profile details 15.You cannot manually bind the configuration created with this profile to a specific host since it is automatically performed after the first deploy. If you want to bind manually, do the following: a. Go to the Hosts list. b. Double-click the specific host. c. Manually bind the configuration from the Binding panel.6.3 Creating software packages You may find it useful to add some specific software installations at the end of the deployment process. Software packages can let you upgrade your bare bones system installation to a bare metal machine building process that leads to a working computer equipped with the needed applications. If the required software is provided with the installation CDs, you can use the previous wizard steps (as described in 6.2, “Creating an unattended setup profile” on page 265), and select those needed programs from the Additional software list (see Figure 6-8 on page 271). Otherwise you can use the “Software packages” feature of Tivoli Provisioning Manager for OS Deployment to install some programs or to perform other configuration operations on the target machine. In the following paragraphs, we describe how to create and configure software packages and how to bind them to target machines. Chapter 6. Installing Linux systems 275
  • Our software packages perform the following operations: Install an RPM containing the DHCP server. Copy and unpack the Tivoli Provisioning Manager for OS Deployment installer provided in a tar.gz format. Copy a system file containing release information.6.3.1 RPM software packages Perform the following steps to create the software package that installs the DHCP server from an RPM: 1. Choose the New Software item from OS Deployment → Software Packages. In the first window of the Software Wizard, select RPM as the type of package: Figure 6-15 Choosing the type of software package in the Software Wizard 2. Provide the full path of the RPM package that will be loaded into the Tivoli Provisioning Manager for OS Deployment server. The package that is used is a RPM binary containing the DHCP server.276 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-16 Inserting the full path to the package in the Software Wizard If the RPM is correctly loaded by the wizard, some general information will appear as shown in Figure 6-17.Figure 6-17 General package information in the Software Wizard3. Next, we are prompted to insert a name and a description that will help to identify this software package through the list. We recommend that you insert a descriptive value. See Figure 6-18 on page 278. Chapter 6. Installing Linux systems 277
  • Figure 6-18 Name and description for the package in the Software Wizard 4. Next the most important window of the wizard is shown asking us to define the following: – When to apply the software package. – Where to copy the RPM package. – Which command to use to install the RPM. Figure 6-19 shows the selected values. Figure 6-19 Software package parameters in the Software Wizard 5. If all the wizard steps are performed correctly, you will get a message stating that “Your software package was successfully created” as shown in Figure 6-19.278 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-20 Outcome message in the Software Wizard In the list of the software packages, it will appear as shown in Figure 6-21.Figure 6-21 List of the software packages6. If you right-click each software package and select Reorder software package, you can see all the existing software packages grouped by the step of the deployment process, which is when they will be added to the target system. It is very important to choose the right order for each package in the list. We choose to add the software packages after one additional reboot of the system. Chapter 6. Installing Linux systems 279
  • Figure 6-22 Software package order in the deployment process6.3.2 Copying and unpacking software packages Perform the following steps to copy and unpack the software packages: 1. For the Tivoli Provisioning Manager for OS Deployment installer (we chose to copy and unpack it on the target machine) which is provided in a tar.gz format, we need to create another software package with the “Custom action“ option (see Figure 6-23): Figure 6-23 Software package type in the Software Wizard280 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 2. Choose to copy a file on the target system, since we have to put the installer on the machine where it will be installed.Figure 6-24 Type of operation in the Software Wizard3. Be careful when you are prompted to insert the source folder. Here, you will have to insert the path of the folder containing the installer that will be copied on to the target machine (see Figure 6-25).Figure 6-25 Source path of the file in the Software Wizard4. As previously described, we need to insert a name to identify this profile in the database as shown in Figure 6-26 on page 282. Chapter 6. Installing Linux systems 281
  • Figure 6-26 Name and description for the package in the Software Wizard 5. The last panel of the wizard requires you to insert the following parameters: – Destination path /usr/local – Command line cd /usr/local ; gunzip -c /usr/local/TPMfOSd-5.1.000.32-linux.tar.gz | tar -xvf - – Installation stage After one additional reboot. Note that in the command line section, we insert commands that unpack the Tivoli Provisioning Manager for OS Deployment installer as shown in Figure 6-27. Figure 6-27 Script details in the Software Wizard After the wizard steps are completed, the creation of the software package starts.282 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 6.3.3 Executing a command In this last package, we want to copy in the root directory of the target machine, a file (/proc/version) containing some useful release information. 1. To achieve this, we create a new software package called rhel release that executes a single command in order to copy the specific file on the required destination. After choosing the A custom action on the target computer option, select the Execute a single command option as shown in Figure 6-28. Figure 6-28 Type of software package in the Software Wizard The syntax of the command that will perform the copy is as follows: cp /proc/version /rhel_release When the software package is deployed, we will have this new file in the root folder of the target machine as shown in Figure 6-29. Figure 6-29 Command details in the Software Wizard6.3.4 Software packages binding As for configurations, you can bind software packages to hosts in order to create a permanent relationship and automatically install them during each deployment performed. This operation can be performed in the following two ways: Chapter 6. Installing Linux systems 283
  • Manually, for each host-software package Automatically with binding rules Manually binding software packages to a host To perform manual binding 1. Select the host to which you want to associate a software binding from the Hosts list. 2. Double-click the host name to accessing to the Binding panel. 3. Add the specific software package or configuration. We manually bind to the target host two of the three packages created: – DHCP server RPM – Tivoli Provisioning Manager for OS Deployment installer Figure 6-30 shows what we did. Figure 6-30 Our bindings for the target computer Automatically binding software packages to a host You can also create software packages that can be automatically binded to a host using matching criteria. Using this process you avoid adding each software package to each host manually. We can copy the file containing the release information, the rhel release software package, for only one particular Linux distribution. This can be done without284 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • manually binding the software package for each of the several hosts where thedistribution will be deployed. We can also add a binding rule to the softwarepackage in order to bind it automatically to the hosts where that specific Linuxrelease will be deployed.To achieve this, perform the following steps:1. Add a new binding rule for the rhel release package.2. Select, as matching criteria, that the deployed profile is the specific RHEL 4 unattended setup profile.Figure 6-31 Binding rule for the rhel release software packageAs you can see in the binding panel of the specific host, the rhel release softwarepackage was automatically binded since the RHEL 4 Linux unattended profile(the matching criteria) was already bound. During deployment, this softwarepackage is added to the system as the previous two (DHCP server RPM andTivoli Provisioning Manager for OS Deployment installer).Figure 6-32 Software package binding for the target computer Chapter 6. Installing Linux systems 285
  • 6.4 The deployment process After creating the profile and the software packages, choose the related bindings. We can start the deploy on the specific host. In the Deploy now window, choose the following: The deployment scheme to use The profile to deploy The software packages to add If you manually bound for the specific host the previously created configuration and software packages in the previous step, they are checked in the related lists, namely Edit manual configuration bindings and Edit software configuration bindings. Since these lists only show the manual link to profiles and packages, the binding entailed by the automatic rules are not checked even if they will be deployed. Figure 6-33 and Figure 6-34 on page 287 show that we want to deploy the Linux RHEL 4 profile with the DHCP and Tivoli Provisioning Manager for OS Deployment software packages manually added. Even if the rhel release software package is not checked in the list (since we did not add it manually) it will be deployed because it matches its binding rule. Figure 6-33 Deploy now options286 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-34 Manual software bindingsAfter starting the deployment from the Web console, the client machine performsa network boot in order to load the Tivoli Provisioning Manager for OSDeployment mini operating system. This is a simple operating system thatcontacts the Tivoli Provisioning Manager for OS Deployment server and runs thedeploy on the target machine.Following is the sequence of the steps performed on the client machine duringthe deploy of our profile with the binded software packages.1. The client machine boots from the network and loads the Tivoli Provisioning Manager for OS Deployment mini operating system.2. The deployment starts on the client machine.3. After the “Starting system installation” step, the Linux installer, called Anaconda, is started on the client machine.4. Anaconda performs the unattended system installation on the client machine.5. The client machine reboots from the hard disk, and the early installed Linux is loaded to install the software packages binded to the host.6. The client machine reboots, forcing the loading of Tivoli Provisioning Manager for OS Deployment mini operating system for the last deployment steps.7. The client machine informs the customer that the deploy ended correctly. Chapter 6. Installing Linux systems 287
  • Note: The second reboot after OS installation and before software installation (step 5) is option, but is recommended to minimize the risk of a file system corruption. Figure 6-35 shows the sequence of operations performed on the client machine after booting from the network. You can see the Tivoli Provisioning Manager for OS Deployment panel on the client that displays the action that is currently being performed. Figure 6-35 Copy operating system files step on the target machine Figure 6-36 on page 289 shows the last step performed on the target computer before the Linux installer is loaded. There is a Tivoli button in this window that helps you during troubleshooting operations.288 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-36 Starting system installation on the target machineAfter the Linux installation is configured by the deployment process, the installer(called Anaconda) is launched to perform the unattended installation. All theparameters provided in this step can be modified through editing the profile andthe binded configuration from the Web console.Figure 6-37 The Linux installer started on the target clientAfter Anaconda completes its tasks, the system reboots from hard disk and theLinux operating system installed earlier is loaded. During this step, the softwarepackages are also installed. Chapter 6. Installing Linux systems 289
  • Figure 6-38 Linux is loaded on the target computer Figure 6-39 Panel before the last reboot Finally the target machine forces another reboot from Tivoli Provisioning Manager for OS Deployment mini operating system in order to complete the remaining operations and to inform the user of the status. If the installation of the operating system encountered some problems, some errors may appear on the client during this last step. As mentioned earlier, you may find the Tivoli button very useful to show errors or to upload logs.290 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-40 Last installation step on the target computerFigure 6-41 displays the message showing the successful completion of thedeployment operation.Figure 6-41 Outcome message on the target machineAfter completion, we are prompted to shutdown or reboot the freshly installedsystem. In order to check whether the bare metal machine is working asrequired, we run the client machine and log into the system.The DHCP server package was correctly installed since the rpm qa commandshows it. Chapter 6. Installing Linux systems 291
  • Figure 6-42 Checking DHCP server RPM installation Also the Tivoli Provisioning Manager for OS Deployment installer was correctly copied and unpacked as shown in Figure 6-43. Figure 6-43 Checking the Tivoli Provisioning Manager for OS Deployment installer Finally the rhel release package was added to the deploy since we found the copied file in the root directory, as shown in Figure 6-44. Even if this software package was not manually added to the binding list, it matched the binding rule that we created and was added to the deploy. Figure 6-44 Checking rhel release package6.5 Cloning a machine Another important feature of Tivoli Provisioning Manager for OS Deployment is the cloning of machines with the Windows or Linux operating system running. Creating a clone of a machine means building an image of the content its disks contain:292 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • The operating system The operating system settings and drivers The software and the data During the cloning operations, all the content of the disks of a source machine are imported as an image on the server to deploy it at a later time. This means that you can clone a machine used as a prototype and deploy its image on several machines that appear as the original one. Obviously, the cloning operation implies the customizing of some basic settings on each target machine. We show how to capture the image of a source machine running a Linux operating system and how to deploy it taking care of some useful advice. In the following sections we used the Linux RHEL 4 computer, which was created earlier, as a source machine. We deploy its cloned profile on a machine of the same model but with a hard disk of different capacity. Although a wide range of modifications are possible on each captured profile, the cloning procedure should be performed between machines of similar models in order to avoid incompatibility problems. We explain how to customize a cloned image modifying the partition scheme to use all of the disk size of the target machine. The cloning steps may be summarized into the following: Run a “make a new image” task from the source client to capture its image. Modify the captured profile on the server to fit the destination machine characteristics (we will change only the partition scheme). Deploy the profile on the destination machine.6.5.1 Capturing the image Before creating an image of a source machine, you need to perform some cleaning steps that will remove unwanted files: Empty the trash Delete temporary directories and files Disconnect network drives and remote printers Note that the Tivoli Provisioning Manager for OS Deployment supports both GRUB and LILO bootloaders, but we strongly suggest using the former instead of the latter. If you do not plan to use the Redeployment feature, it can be installed on the MBR or on the boot sector of the Linux boot partition. The cloning operation on the Linux machine does not require that you install a specific software as Sysprep for Windows systems. For Linux cloned profiles, Tivoli Provisioning Manager for OS Deployment automatically copies and uses a Chapter 6. Installing Linux systems 293
  • simple tool called Linprep that configures the destination machine after the deployment with the needed customization. Linprep is used only for cloning profiles and it is copied during deployment on the target machine. It is run at the first boot of the target machine just after the deploy. When the “Starting system installation” step of the deployment process completes and the machine boots the early installed system, it is launched by a script in /etc/init.d at runlevel 1. The customizations performed are as follows: Reconfigure the network settings, the primary network interface (DHCP or static ip address), and the gateway and similar tasks. Reinstall the bootloader (GRUB or LILO). The bootloader is software that stores the physical address of the kernel to load. Since this address changes at each new deployment, the bootloader cannot be installed by Tivoli Provisioning Manager for OS Deployment during the deployment operations; therefore, Linprep runs LILO or GRUB installers at the first boot of the system when this address is known and will not change. After executing Linprep, the Linux system is rebooted (other runlevel 1 scripts are not executed) and the deployment completes. Note: In future releases, it is expected that Tivoli Provisioning Manager for OS Deployment will use the Web interface extension interface instead of Linprep. 1. The first step to start the capture is to access the source machine and boot it from the network in order to start the Admin Toolkit interface on the client. In future releases, it will be possible to capture the image of a machine from the Web console, while in the current release you have to physically access the source client. You may need to manually bind the Admin Toolkit interface on the specific machine; otherwise, no operations will be allowed on it. Figure 6-45 on page 294 shows the main menu of the Admin Toolkit interface. Figure 6-45 Main menu of the Admin Toolkit interface294 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 2. Since we need to capture an image of this machine, choose the make a new image option.Figure 6-46 Make a new image task on the Admin Toolkit interface3. Insert the name of the profile that will contain this image (cloneRHEL4), and accept to create a default configuration (automatically bound) for it.Figure 6-47 Inserting the profile name in the Admin Toolkit interface Chapter 6. Installing Linux systems 295
  • Figure 6-48 Default configuration in the Admin Toolkit interface 4. At the end of the operations, if the captured image is correctly stored in a profile, you will see the message Operation Completed as shown in Figure 6-49 on page 296. Figure 6-49 Outcome message in the Admin Toolkit interface 5. You can browse the Web console to find the captured profile in the list as shown in Figure 6-50.296 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-50 List of profiles in the Tivoli Provisioning Manager for OS Deployment server6.5.2 Customizing the captured profile During the deployment of the captured image, we advise you to ensure that Tivoli Provisioning Manager for OS Deployment gets enough disk space for the deployment operations. On the target machine, the process uses both the unpartitioned space at the end of the hard disk and the free space at the end of the last partition. The sum of these areas must be large enough for storing all partition images that are deployed at the same time on the client computer—it should typically be half of the size of the data on the hard disk—the available space should be 1 GB if your OS partition contains about 2 GB of data. We suggest that you ensure that the swap partition of the image is not at the end of the disk when deploying a Linux system profile, since this partition is usually small and if there is no unpartitioned space (as in our case where we will partition all the available disk space), the deployment of the cloned profile will fail because of insufficient free disk space. Since our destination machine has a hard disk with higher disk size (10GB), we modify the captured profile to use the 100% of the disk space for the last root partition. We also check that the last partition (since we will not leave any unpartitioned space) will be enough for the deployment process. Figure 6-51 shows our profile after the capturing. Chapter 6. Installing Linux systems 297
  • Figure 6-51 The partition layout of the captured image Next, set the third partition, where the root file system will be mounted, to use all the available disk space as shown in Figure 6-52. Figure 6-52 Using all the available disk space After the changes, the partition scheme will use all the available disk space of the target machine (10GB) instead of the fixed size of the source machine (8GB), as shown in Figure 6-53 on page 298. Figure 6-53 The partition layout after the changes298 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 6.6 Deploying the cloned profile After the customization steps, we can distribute the cloned profile to the target machine. We select the destination client from the hosts list and deploy the cloneRHEL4 profile. Figure 6-54 Deploying the cloned profile cloneRHEL4 Note: In the manual bindings of the software packages, there is no software selected since we are deploying a cloned profile and we will get all the installed software from the source machine. Figure 6-55 No manual bindings for software packages Chapter 6. Installing Linux systems 299
  • During the deploying operations, the target machine performs the following steps: Boot from the network to connect to Tivoli Provisioning Manager for OS Deployment server. Start the deployment. After the “Starting system installation” step, run the earlier installed system. Run Linprep, then reboot. Boot from the network (forced by the deployment process) to terminate the installation. Figure 6-56 shows that the deployment process is started on the client. Figure 6-56 Deployment step on the client After the “Starting system installation” step, the system runs the earlier installed Linux. Then Linprep is launched to perform the needed customization. After the configuration ends, a reboot from Tivoli Provisioning Manager for OS Deployment mini operating system is forced and final deployment steps are performed. Note: Note that Linprep is not customizable. You can only customize the profile you have to deploy. Figure 6-57 shows one of the operations performed after the reboot—resizing the last partition used as temporary storage.300 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 6-57 Last deployment stepsAt the end of the process, we receive a message as shown in Figure 6-58.Figure 6-58 Outcome message at the end of the cloning processIf we run Linux, we can check the following: All the software of the source machine that was installed on the destination. For example, the DHCP RPM was installed even if not binded. Whether the disk partitioning is correctly set. The root partition uses all the available space. Linprep log that shows the Linprep operations.Figure 6-59 on page 301 shows the disk size to 9 GB of the last root partition andthe DHCP server installed as it was on the source machine.Figure 6-59 DHCP server installedFor an example of Linprep.log, see Example 6-1. Chapter 6. Installing Linux systems 301
  • Example 6-1 Linprep.log Distribution : unknown RedHat Parsing /etc/linprep.inf..... Time Zone = 110 Boot loader = grub Root partition = disk://0:3 Boot partition = disk://0:2 BootLoaderLocation = disk://0:0 MacAddress = * Language -> Keyboard = 0409 Host Name = pc-000C2955E702 Found GRUB bootloader Changing administrator password Change root password: executing: echo root:XXXX | /usr/sbin/chpasswd Changing DNS settings Generate new /etc/resolv.conf (DNS) Changing network configuration Modifying /etc/sysconfig/network OK Modifing /etc/sysconfig/network-scripts/ifcfg-eth0 DHCP actived OK Changing hostname Modifying /etc/hosts Adding 127.0.0.1localhost pc-000C2955E702 OK Changing timezone Modifing file /etc/sysconfig/clock new Timezone : Etc/GMT+1 OK Changing keyboard mapping Adjusting keyboard locale console keytable : us ERROR with file /etc/X11/XF86Config-4 : No such file or directory Unable to open device /dev/sda Found a valid RAD protected MBR on /dev/hda Using /dev/hda as root device Installing GRUB on MBR Executing grub-install --recheck (hd0) Saving MBR Linprep finished.302 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • 7 Chapter 7. Common deployment features In this chapter we discuss deployment features that are common to all operating system deployments. The chapter contains the following sections: “Configuring RAID arrays” on page 304 “Software package rules and bindings” on page 315 “Collecting inventory from the target machines” on page 328 “Device driver injection” on page 332 “Understanding the host boot settings” on page 345 “User administration” on page 353© Copyright IBM Corp. 2007. All rights reserved. 303
  • 7.1 Configuring RAID arrays When building servers, it is a typical requirement that the RAID configuration on the server be done before the Operating System is installed. In this chapter, we take you through the process of having Tivoli Provisioning Manager for OS Deployment do the work for you. Remember also that when servers are decommissioned, and they contained sensitive data, it may be a requirement to formally remove the data from the RAID disks, which can also be accomplished with this technique. Typically each hardware manufacturer has their own tools to configure their own RAID configuration, and these differences are not important for the purposes of this chapter. We focus on the general principles, and we use the IBM System x™ Server RAID environment as an example. HP provides a toolkit, which you can download from the following Web site: http://h18004.www1.hp.com/products/servers/management/toolkit/index.htm l The toolkits for DELL can be found at the following Web sites: http://www.dell.com/content/topics/global.aspx/sys_mgmt/en/server_deplo y?c=us&cs=04&l=en&s=bsd http://support.dell.com/support/downloads/download.aspx?fileid=123204 IBM provides a toolkit to automate the RAID configuration process called the IBM ServerGuide™ Scripting Toolkit. The details are at the following Web site: http://www-03.ibm.com/systems/management/sgstk.html Details of the latest release of the toolkit available at the time of publication can be found at the following Web site: http://www-304.ibm.com/jct01004c/systems/support/supportsite.wss/docdis play?lndocid=MIGR-53564&brandind=5000008 The ServerGuide Scripting Toolkit provides for the following three deployment scenarios for the configuration process: A DOS-startable CD or standalone DOS-startable diskette with data CD A DOS-startable diskette with network share A Remote Supervisor Adapter II or BladeCenter® Management Module and network share.304 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • We will build a DOS Bootable Diskette with the appropriate configuration files and executables, that when booted, performs the required RAID configuration without any manual intervention. Install the ServerGuide Scripting Toolkit in standalone mode on your Windows preparation machine. The machine that we used to prepare the DOS image was Windows. This can also be done in a Linux environment, but that scenario is not covered here. You will also find it useful to have a real diskette drive available to you, but if that is not the case, then virtual alternatives can be used. Our preparation station was Windows running as a VMWare guest operating system, which allows for the attachment and manipulation of virtual diskette images. There are also various shareware and open source alternatives available. You might use Virtual Floppy Drive 2.1, which is a free tool that can be downloaded from the following Web site: http://chitchat.at.infoseek.co.jp/vmware/vfd.html#download. There are other tools available with a similar function.7.1.1 Building the bootable DOS diskette When you install the ServerGuide Scripting Toolkit in standalone mode, you will see that there are some supplied bootable DOS images under the C:sgsharesgdeploysgtbootimages directory; however, we are going to use the sample under C:sgsharesgdeploysgtkadsimages called tk_raid.vfd. 1. Select the sample that you want to use, and attach it to the VMWare virtual machine, as shown in Figure 7-2 on page 306. After a virtual machine is booted, it is possible to dynamically change the attached virtual floppy as shown in Figure 7-1. Figure 7-1 Changing an attached virtual floppy Chapter 7. Common deployment features 305
  • Figure 7-2 Attaching sample diskette image to VMWare machine 2. Look at the A: drive within the virtual machine, and you will see something similar to Figure 7-3 on page 307. Note that this gives us full read and write access to the image. There are a number of helper utilities provided by the ServerGuide scripting Toolkit, which are documented in Chapter 3. “Customizing Toolkit Scenarios” of the IBM ServerGuide Scripting Toolkit User’s Reference Version 1.3. The guide itself is located under: C:sgsharesgdeploysgtkdocs (The pdf is put on disk when toolkit is installed.).306 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-3 Browse the attached sample diskette image The significant logic of the boot process for this diskette is as follows: autoexec.bat is run which does the following: a. Runs usrvars.bat to set RD_FILE variable to identify the RAID configuration file that will be used by the praid.exe RAID configuration binary. b. Runs tkzip.exe to copy the ServerGuide Scripting Toolkit utilities to the RAMDRIVE identified by the %RAMDSK% environment variable. c. Runs the praid.exe utility with the %RD_FILE% configuration file to configure the RAID array. d. Saves the return code into non volatile CMOS storage. e. Reboots the machine.3. Make the appropriate praid.exe configuration file modifications using the samples in the following directory as a template: C:sgsharesgdeploysgtkexamplesraidtemplate.ini We include RAID5HSP.ini as a sample of how you can do RAID 5 configuration that uses all available drives, keeping one as a hot standby. See Example 7-1 on page 308. Chapter 7. Common deployment features 307
  • Example 7-1 Sample praid.exe configuration file ; * Policy.RAID-5-HSP ; * ; * This policy configures a RAID controller with a RAID-5 array using ; * all available drives and a single hot-spare drive. ; * ; * This policy will be used on the following RAID controllers: ; * - ServeRAID-4H ; * - ServeRAID-4Mx ; * - ServeRAID-4Lx ; * - ServeRAID-5i ; * - ServeRAID-6i/6i+ ; * - ServeRAID-6M ; * - ServeRAID-7k ; * - ServeRAID-7t ; * - ServeRAID-8i [Policy.RAID-5-HSP] AppliesTo.1 = t:ServeRAID-4H AppliesTo.2 = t:ServeRAID-4Mx AppliesTo.3 = t:ServeRAID-4Lx AppliesTo.4 = t:ServeRAID-5i AppliesTo.5 = t:ServeRAID-6i AppliesTo.6 = t:ServeRAID-6M AppliesTo.7 = t:ServeRAID-7k AppliesTo.8 = t:ServeRAID-7t AppliesTo.9 = t:ServeRAID-8i Array_Mode = CUSTOM Array.A = ALL Hotspares = 1 Logical_Mode = CUSTOM Logical.1 = A:FILL:5 ;Note: Uncomment the policy name and AppliesTo.1 to activate this policy. ; * Policy.auto-mode ; *308 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • ; * This policy configures all controllers with PRAID default valuesfor arrays; * and logical drives.; * (Any RAID controller not configured by Policy.RAID-5-HSP will usethis policy.); * Note: PRAID default configuration values include a RAID-1 array oncontrollers with 2; * drives. The RAID level varies for controllers with morethan 2 drives.; * See the PRAID documentation for more details.;[Policy.auto-mode];AppliesTo.1 = ALL4. Because of the limited space on the virtual floppy disk, we need to package up the ServerGuide Scripting Toolkit and any RAID configuration files you created as a self-extracting zip file. There are utilities available to do this, such as the Pkware family that has zip, unzip, and utilities to convert zip files to self extracting .exe files. If we continue to edit the floppy disk according to our needs, when this is detached from the virtual machine, it will be transportable. Example 7-2 shows how we create a zip file using Pkware.Example 7-2 Using Pkware to create a zip fileC:sgshare>.pkwarepkzip.exe raid.zip .raid*.*PKZIP (R) FAST! Create/Update Utility Version 2.04g 02-01-93Copr. 1989-1993 PKWARE Inc. All Rights Reserved. Shareware VersionPKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745? 80486 CPU detected.? XMS version 2.00 detected.? DPMI version 0.90 detected.? Using Normal Compression.Creating ZIP: RAID.ZIP Adding: ACU.EXE Deflating (59%), done. Adding: ACUAHCI.EXE Deflating (64%), done. Adding: ACUICHSV.EXE Deflating (64%), done. Adding: ACUSAS.EXE Deflating (63%), done. Adding: ACUSAS8E.EXE Deflating (58%), done. Adding: ADSCFG.BAT Deflating (77%), done. Adding: ALTBOOT.EXE Deflating (55%), done. Chapter 7. Common deployment features 309
  • Adding: CFG1030.EXE Deflating (57%), done. Adding: CFGGEN.EXE Deflating (40%), done. Adding: CFGRAID.BAT Deflating (82%), done. Adding: CKVARS.BAT Deflating (82%), done. Adding: CLINI.EXE Deflating (55%), done. Adding: CLRENV.BAT Deflating (64%), done. Adding: CLRFIB.BAT Deflating (59%), done. Adding: CLRNET.BAT Deflating (60%), done. Adding: CLROS.BAT Deflating (83%), done. Adding: CLRUPDS.BAT Deflating (61%), done. Adding: DYNALOAD.COM Deflating (21%), done. Adding: HWDETECT.EXE Deflating (52%), done. Adding: IPSRASPI.SYS Deflating (87%), done. Adding: IPSSEND.EXE Deflating (66%), done. Adding: LOADRAID.BAT Deflati (71%), done. Adding: PRAID.EXE Deflating (61%), done. Adding: RAIDCLN.BAT Deflating (78%), done. Adding: RAIDSEL.EXE Deflating (52%), done. Adding: REBOOT.COM Storing ( 0%), done. Adding: SAVESTAT.EXE Deflating (52%), done. Adding: SLEEP.EXE Deflating (32%), done. C:sgshare> 5. Now that we created the .zip file, we need to make it a self-extracting .exe file for subsequent expansion in the booted DOS environment. Example 7-3 demonstrates the use of the zip2exe.exe utility. Example 7-3 Creating a self extracting zip file C:sgshare>.pkwarezip2exe raid.zip ZIP2EXE (tm) Self-Extract Creator Version 2.04g 02-01-93 Copyr. 1989-1993 PKWARE Inc. All Rights Reserved. Shareware Version ? Creating a Full Featured Self Extractor RAID.ZIP => RAID.EXE 6. Finally we have to copy the newly created self-extracting zip file to the diskette as in Example 7-4. Example 7-4 Copy the self-extracting zip file to the diskette C:sgshare>xcopy RAID.EXE a:310 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • C:RAID.EXE1 File(s) copied7. If you are working in a real environment with real diskettes, you can make a diskette image with utilities such as RawWrite.exe, as illustrated in Figure 7-4, and save it to C:WorkRAID.VFD.Figure 7-4 Capturing virtual image from A: drive8. You could alternatively use the rbagent command as in Example 7-5.Example 7-5 Creating an image from a diskette driverbagent mkimage a: net://images/diskette.img Also look at the helper batch files under c:sgdeploysgtkboot as they may help you with the creation of these images. At this point we finished creating our DOS boot disk that will perform our required RAID configuration. We now need to integrate this image into our Tivoli Provisioning Manager for OS Deployment deployment scheme.9. Create a software package, as in Figure 7-5 on page 312. Chapter 7. Common deployment features 311
  • Figure 7-5 Create a software package for a ramdisk boot 10.Elect to make a custom action, as in Figure 7-6. Figure 7-6 Software package custom action 11.Our software package build dialog continues as in Figure 7-7 on page 313.312 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-7 Select the software package custom action type12.In Figure 7-8, select to boot from a floppy disk.Figure 7-8 Boot from a virtual floppy disk.13.Give the software package a name, as in Figure 7-9.Figure 7-9 Name the DOS ramdisk software package14.Direct the dialogs to our floppy disk, as in Figure 7-10 on page 314. Chapter 7. Common deployment features 313
  • Figure 7-10 Software package boot diskette location 15.The creation dialog also then prompts us for the installation step for this DOS boot process. We will change this later, so the default is good for now. This is shown in Figure 7-11. Figure 7-11 Select installation step for the RAID configuration 16.Continue the software package until it is successfully created, and then use the OS Deployment → Software Packages → Reorder Software dialog to make sure that the RAID configuration happens before the OS is installed. When this process is finished, the deployment step order looks similar to Figure 7-12 on page 315.314 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-12 Deployment steps for software packages including RAID configuration7.2 Software package rules and bindings We need to bind a software package to the OS profile if we want it installed as a part of the same workflow. 1. From within the details of the software package, we create a new rule, as in Figure 7-13 on page 316. The details of the rule can be many, but only want this software package to be bound to the Windows 2003 unattended installation profile. Chapter 7. Common deployment features 315
  • Figure 7-13 Binding a software package to an OS profile 2. In this binding criteria, you might choose to make use of the hardware inventory that is available to you from the scan done by Tivoli Provisioning Manager for OS Deployment. The data returned by the scanning process is controlled by the deployment scheme, as shown in Figure 7-14 on page 317. Note that this data just supplements that associated with the host definition itself that may contain other data such as geographical location, department, and building.316 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-14 Control inventory data from the deployment schema3. In Figure 7-15 on page 318, we define the binding criteria with the software package. In this simple example, we only define the profile name. Chapter 7. Common deployment features 317
  • Figure 7-15 Define software package binding criteria 4. When this process completes, and the OS Profile is deployed to the target, review the details of the target host as in Figure 7-16 on page 319, where you can see the software package bound to the deployment of the OS profile.318 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-16 Browse the host OS profile and software package bindings7.2.1 Binding software packages to deployment schemes When you deploy an OS profile to a machine, you may also want to deploy one or more software packages. In our case, we want to add and remove some Microsoft components and also restore the user settings as we deploy WIndows XP. Following is how we link these three components. 1. One way to bind the components is to use deployment schemes, but as you see in Figure 7-17 on page 320, there are no bound software packages by default. Chapter 7. Common deployment features 319
  • Figure 7-17 Deployment scheme with no bound software packages 2. As you deploy a profile to a target, name the profile, and also an associated deployment scheme, as shown in Figure 7-18 on page 321.320 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-18 Choose a deployment scheme for a profile3. Let us now look at the details of the schema called Deployment. If you look at the bottom of the panel in Figure 7-17 on page 320, you will see that by default there are no software packages bound to the deployment scheme. We will now bind our two software packages. So select Edit in the Software Bindings section of the schema definition in Figure 7-17 on page 320, and you will see the currently defined software packages as in Figure 7-19.Figure 7-19 Software packages available for binding to deployment schema4. We select them all and continue, as shown in Figure 7-20 on page 322. Chapter 7. Common deployment features 321
  • Figure 7-20 Bind all software packages to deployment schema When this is complete you, it will look similar to Figure 7-21, showing that the software packages were added to the deployment scheme. Figure 7-21 Amended scheme with bound software packages Note that this is one technique in using bindings. Rather than bind the software packages to the scheme you can also bind them to the host at the time of deployment. This will achieve the same result but only for this deployment. For more permanent results, we suggest that you modify the scheme bindings as we did. See Figure 7-22 on page 323 for details of how this is done.322 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-22 Change the software packaging bindings at deployment time5. You may also want to change the order in which the software packages are deployed, as they may have dependencies on each other. You can do this as in Figure 7-23 on page 324. This is done from OS Deployment > Software Packages > Reorder Software. Here you can see that the User State Migration and the Windows component activities are all completed as a part of the OS installation. Chapter 7. Common deployment features 323
  • Figure 7-23 Re ordering the installation order of the software packages7.2.2 Advanced binding scenarios Consider now that you may want to perform some advanced bindings of profiles to machines. What scenarios might you want to support? Consider the following: My image needs at least a 8 GB partition on the first physical disk. My image runs database software, so it needs at least 2 GB of physical memory. Use of free form text in the binding rules allows us to do this. You can interrogate any field in the records that you see defined in Table 7-2 on page 326. Note that you might want to look into the two parts of the RDBMS schema that hold information of interest to use. The tables are shown in Table 7-1. Table 7-1 Schema tables Bill of materials related Machine configuration related BOM SoftwareProfile DiskInventory SoftwareItem DMIInventory GroupingRule324 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Bill of materials related Machine configuration related PCIInventory Groups PCIDescription SystemProfile Deployment ErrorLog Settings UserProfileThe schema is created automatically when the Rembo TCP to ODBC gatewayservice on Windows starts. The equivalent daemon on Unix looks similar toExample 7-6.Example 7-6 Active Tivoli Provisioning Manager for OS database interface processusr/lib/java/jre/bin/java -cp/usr/local/tpmfos-5.1/dbgw.jar:/usr/local/tpmfos-5.1/db2jcc.jar:/usr/local/tpmfos-5.1/db2jcc_license_cu.jar-Djdbc.drivers=com.ibm.db2.jcc.DB2Driver com.rembo.dbgw.DbgwThere are several ways to look at the defined schema and its details.Example 7-7 shows some tips for use in a DB2 environment. You can also usethe DB2 command center if you have access to a graphical environment, whichyou start with the db2cc command.Example 7-7 Listing the Tivoli Provisioning Manager for OS Deployment schema details#!/bin/sh# source the DB2 environment. /home/db2inst1/sqllib/db2profile# connect to the databasedb2 connect to tpmfosd user db2inst1 using db2inst1# list all the tables in the schemadb2 list tables# list the details of the BOM tabledb2 describe table BOM# terminate DB2 connctiondb2 connect reset Chapter 7. Common deployment features 325
  • Tip: A lot of the table and column names in the schema have quotation mark (“) characters in their name. You have to escape this character in a unix shell. To make your life easier, use DDL, for example su - db2inst1 -c “db2 -tvf cmds.ddl, where cmds.ddl does not have the db2 command prefix and the lines end with a semicolon (;) character. To use freeform text in our binding rules, we address the record and not the table. In Table 7-2, you can see the association between the schema table and the record name. Table 7-2 Mapping rule records to RDBMS schema tables Record name Table name Disk DiskInventory DMI DMIInventory Order BOM User UserProfile System SystemProfile PCI PCIInventory We list the DiskInventory table, as shown in Example 7-8. As we said before, we have had to use the escape character in front of the table name, as the shell will strip the leading and trailing quotation mark (“) from some of the column names. Example 7-8 Listing the details of he DiskInventory table manchester:/usr/local/scripts # db2 describe table "DiskInventory" Column Type Type name schema name Length Scale Nulls ------------------------------ --------- ------------------ -------- ---------- BomID SYSIBM INTEGER 4 0 Yes DiskID SYSIBM INTEGER 4 0 Yes Controller SYSIBM SMALLINT 2 0 Yes Device SYSIBM INTEGER 4 0 Yes Type SYSIBM VARCHAR 5 0 Yes Media SYSIBM VARCHAR 8 0 Yes Removable SYSIBM CHARACTER 1 0 Yes ProtSupport SYSIBM CHARACTER 1 0 Yes UDMASupport SYSIBM CHARACTER 1 0 Yes BiosSize SYSIBM INTEGER 4 0 Yes326 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • DiskSize SYSIBM INTEGER 4 0 YesModel SYSIBM VARCHAR 40 0 YesFirmware SYSIBM VARCHAR 8 0 YesSerial SYSIBM VARCHAR 20 0 YesATA48bits SYSIBM CHARACTER 1 0 Yes 15 record(s) selected.We want to use the value of the DiskSize column from the DiskInventory table inmy binding rule. This translates to the DiskSize field of the Disk record when wewrite the rule. There may also be multiple physical disks on the machine. So howdo we just check the size of the first physical disk? All instances of Disk areloaded into an array and are addressable by their array index within the rule.So, the first physical disk is addressed as Disk[0], and to look at the physicalsize of the first disk, you use Disk[0] DiskSize within your rule record. To decideif the value of this field is appropriate for our needs, we have to apply somelogical operators to is value.The available operators are shown in Table 7-3.Table 7-3 Free form rule logical operators Operator Meaning < is smaller than <= is less than or equal to => is greater than or equal to > is greater than == is equal to != is not equal to && logical AND operator || logical OR operatorSo finally, our free form rule to bind profiles to computers that have their firstphysical hard disk that is greater than or equal to 8 Gigabytes, looks like that inExample 7-9 on page 328. Note that this expression is just going to look in thefirst two memory slots of the motherboard. The DMI schema supports up to 8, soyou might want to extend the expression to sum the values from all eight slots. Chapter 7. Common deployment features 327
  • Example 7-9 Free form binding rule for selecting disk size of target Disk[0].DiskSize > 8*1024*1024 && (DMI.Mem1Size+DMI.Mem2Size) >= 2*1024*10247.3 Collecting inventory from the target machines In the previous section, we showed you how to use the information collected about the target machine. Here we discuss how this information is collected and also how you can browse it interactively from the Tivoli Provisioning Manager for OS Deployment interface. 1. Within the definition of a deployment scheme, we chose when the inventory of the target machine is done and what information is taken. This can be seen in Figure 7-24, where we opted to take all available information at all times. Be clear that this scan is done as a part of the initial capture by Tivoli Provisioning Manager for OS Deployment, for example, its appearance in the Host Monitor list, or subsequently, when a profile is deployed to the target. Figure 7-24 Controlling inventory scope in deployment scheme 2. The data can then be browsed from the Host Monitor, as shown in Figure 7-25 on page 329.328 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-25 Browsing the host inventory3. Now that we have the inventory information we want to treat the machines that match the inventory search all in the same way. To start this process, we create a customer host list as in Figure 7-26.Figure 7-26 Creating a custom host list Chapter 7. Common deployment features 329
  • 4. Now we give it a name, as shown in Figure 7-27. Figure 7-27 Name the custom host list Figure 7-28 Create a custom host list from a query 5. This starts the dialog in Figure 7-29 on page 331 that allows you to search for hosts by their inventory attributes.330 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-29 Selecting host search criteria6. If you know the exact model of your machine community, then you can define a search as in Figure 7-30. Note that we select BOM Information (Bill of Materials) in the dialog check box.Figure 7-30 Wildcard search of machine serial numbers7. If you want to search for hosts, where some software was specifically bound, for example there is no generic binding rule in effect. You can find these hosts as follows. Enter Adobe® Reader% in the search keyword box, and select the Manually bound software box. This identifies all hosts where any version of the Chapter 7. Common deployment features 331
  • Acrobat Reader was installed. This assumes that you are collecting software inventory information that is not the default.7.4 Device driver injection If a required device driver is not contained within the profile that you are deploying to a new target, then at best the hardware on the target will not be exploited, like poor screen performance. At worst, the network card will not initialize correctly, and you will have no network access to correct the problem, mandating a local visit to the machine. An alternative is to have cloned machine images in a profile that contains all possible device drivers. This is not practical for the following reasons: You will have to update the machine profiles as new drivers become available for your hardware. Alternately, you will have to maintain multiple images for different hardware combinations, which is time consuming to produce and expensive with disk utilization. Tivoli Provisioning Manager for OS Deployment adopts a different approach and allows you to inject your 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.7.4.1 How does this process work? All PCI based devices have a unique set of identifiers, as can be seen in the hardware inventory of a sample host for its Ethernet card. You can see in Figure 7-32 on page 333 that this card is uniquely identified by its VendorID and DeviceID. Consider devices that we are handling for the first time. As we need the PCI information to inject the appropriate device driver, it is important that you scan Peripheral Component Interconnect (PCI) devices as a part of the profile deployment. This is controlled in the scheme associated with the profile in the General Settings section, as shown in Figure 7-31 on page 333.332 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-31 Changing the deployment scheme to scan for PCI hardwareMost modern onboard computer peripherals use a PCI bus, but for those thatmay not, we suggest that you integrate the appropriate device drivers into thebase build of the OS image.Figure 7-32 PCI details for ethernet card from hardware inventoryAs the OS is deployed to the target the hardware scan of the target PCI devicesoccurs according to the policy you defined in the deployment scheme. Now look Chapter 7. Common deployment features 333
  • at the rules associated with the device driver software packages, and see if any match. Look at the details of the software package in Figure 7-33. It supports 22 different devices, each identified by unique PCI attributes. Figure 7-33 Sample device driver software package Looking more closely at the rules associated with the software package, we see in Figure 7-34 that we have a VendorID:DeviceID pair that is the same as that of the ethernet card found in the hardware inventory scan of the target PC. Figure 7-34 Matching PCI device driver selection rule Figure 7-35 shows more detail of this binding rule by showing the common name of the device. Figure 7-35 PCI binding rule detail So it appears that when we deploy our OS profile to the target with this hardware, implicit rule binding automatically installs this device driver for us.334 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • It is in this way that only the required drivers are pushed to the target, and one image can support multiple hardware types.7.4.2 Device driver software package rules with a different OS What happens when we deploy a different OS to the same target, and the Windows 2000 driver is different than the Windows XP device driver? If you noticed in our binding rule in Figure 7-35 on page 334, we accept any Windows OS variant to make our device driver eligible for installation. If we want to package different device drivers that cater to the same device but on different operating systems, then we need to specify the required OS variant in the binding rule. You can edit the binding rule associated with the software package as in Figure 7-36. You see here that this package installs on any Windows variant. Figure 7-36 Editing a device driver binding rule Use the list box options shown in Figure 7-37 on page 336 to specify the OS for which this device driver is appropriate. Chapter 7. Common deployment features 335
  • Figure 7-37 Changing the OS selection binding rule Note: Be careful with your device driver binding rules. The default behavior for the device driver software build process includes rules that target all variants of Windows. If you are building images for different versions of Windows, make sure that your OS specific device driver is bound to the appropriate OS. See Figure 7-37.7.4.3 Creating a device driver software package Now, create another software package, but this time direct the build wizard in Figure 7-38 on page 337, to include a device driver in the deployment. 1. In the Figure 7-38 on page 337, we use the VMWare device drivers, for video and network support, and so forth. This is only shown as an example, as there is an MSI to complete the whole installation for you.336 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-38 Device driver injection software package build wizard2. In the case of Windows 2000, 2003, and XP, navigate to the directory containing the .inf and the .cat files for your device driver. When in the right location, the build wizard confirms the driver details as in Figure 7-39.3. You are also asked if you want the software package containing the device driver automatically bound to a machine if there is a matching DMI entry found in the hardware inventory for the target. Select Yes, which has the effect of creating a binding rule that conditionally links the host and the software package.Figure 7-39 Driver injection—device driver details4. Look at the software package binding rules in Figure 7-40 on page 338. Chapter 7. Common deployment features 337
  • Figure 7-40 Implicit binding rules for device driver software package 5. Figure 7-41shows how details of a selected rule appear. Figure 7-41 Implicit rule linking device driver with PCI ID 6. You, once again, are asked at what step in the deployment you want this driver to be injected into the image. We will return to this, but the prompt is shown in Figure 7-42 on page 339.338 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-42 Driver injection step choice7. We repeat this operation for several more VMWare device drivers, until the list of software packages looks like Figure 7-43.Figure 7-43 New device driver software packages8. We have not paid much attention to the order in which the software packages are installed, so let us reorder them. The original order is like Figure 7-44 on page 340. In our case our design needs the device drivers installed and operational before we restore the user settings using USMT over the network, so we need to engineer a reboot of the machine between driver injection and USMT restore. After we complete this, the order looks similar to Figure 7-44 on page 340. We can change this in OS Deployment → Software Packages → Reorder Software. Chapter 7. Common deployment features 339
  • Figure 7-44 Initial step order for device driver software package deployment 9. After we make our changes, the device drivers are installed and the machine reboots before we run the USMT user setting restore process.340 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • Figure 7-45 Final software package deployment steps Restriction: Microsoft does not automatically recognize all devices. If we implicitly bind a device driver software package to a deployment profile, then there may be occasions where this device driver is not installed on the target at deployment time. This can be because the unattended install or the mini sysprep done after a cloned image installation, does not recognize the device. For example, some SCSI devices behave in this way. To circumvent this problem, you can explicitly bind the software package to the profile that will be deployed to the target machine. You may consider binding all such device driver software packages in this way. The up side of this approach is that the driver will be installed, and the only downside is that some device drivers will be deployed to the target that is not used.7.4.4 Quickly building device driver software packages Following is an aid to the quick building of device driver software packages that will help with a pilot deployment of TPM for OS Deployment. Chapter 7. Common deployment features 341
  • Before you start a pilot deployment, gather all of your extra device drivers, and load them under a single mount point on your disk, and then use this script to quickly build the software packages. You can use as many sub directories as you need, and the names of the directories are not important, just make sure that the drivers are expanded. In the case of IBM device drivers for Windows, they are usually shipped as self-extracting executables that install somewhere under C:/IBMTOOLS/DRIVERS. Example 7-10 Script to automate device driver software package building #c:perlbinperl.exe -w # # usage:- device_drivers.pl <path_to_root_of_device_driver_directories> # example:-device_drivers.pl c:/ibmtools/drivers # Richard Hine - ITSO - Feb 2007 # # where has my rbagent binary been installed ? # this assumes that the rbagent.conf file connects you to the required server # if this is not the desired behaviour then modify the rbagent to use the -s switch to identify the TPM server # my $rbagent = "C:Program filescommon filesibm tivolirbagent.exe"; # subroutine to process all files and directories recursively sub recurse($) { my($path) = @_; $path .= / if($path !~ //$/); # check that we have a cat and inf files if (`ls -alr $path|grep -i cat` && `ls -alr $path|grep -i inf`) { print "nnRAD-MKSOFT processing driver in directory $pathnn"; # execute software package build and write all results to STDOUT open(TPM,""$rbagent" rad-mksoft "$path"|"); while (<TPM>) { print "RAD-MKSOFT $_"; } } # loop through the files contained in the directory for my $file (glob($path.*)) { # if the file is a directory then go around again if( -d $file) { recurse($file); }342 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment V5.1
  • }}# process all directories from the passed root directoryrecurse($ARGV[0]);Running the script from Example 7-10 on page 342 with device_drivers.plc:/ibmtools/drivers gives us a result similar to that shown in Example 7-11.Example 7-11 STDOUT from running device_drivers.plRAD-MKSOFT processing driver in directoryC:IBMTOOLSDRIVERS/Q38Z01US/PRO1000/WS03XP32/RAD-MKSOFT IBM Tivoli Provisioning Manager for OS Deployment Webextension v.5.1.0.1 (101.02)RAD-MKSOFT Licensed Materials - Property of IBM. L-DDAC-6RLW3ERAD-MKSOFT (C) Copyright IBM Corporation 1998, 5 2007.RAD-MKSOFT All Rights Reserved. IBM, the IBM logo, and Tivoli aretrademarksRAD-MKSOFT of IBM Corporation in the United States, other countries orboth.RAD-MKSOFT Connect 192.168.56.131 -> 192.168.56.131RAD-MKSOFT Starting Rembo AgentRAD-MKSOFT [00:22:55] <NOT> Parsing driver inlocal://root/C$/IBMTOOLS/DRIVERS/Q38Z01US/PRO1000/WS03XP32/e1000325.infRAD-MKSOFT [Progress] 4% done (Waiting for the server to build * )RAD-MKSOFT [Progress] 82% done (Uploading shared files * Progress:0B/0B Speed:0B/s )RAD-MKSOFT 28 automatic binding rules will be created[Progress] 99%done (Software package creation completed)RAD-MKSOFT { type: "pkg",RAD-MKSOFT content: "win-drv",RAD-MKSOFT class: "Net",RAD-MKSOFT vendor: "Intel",RAD-MKSOFT version: "08/14/2003,7.2.17.0",RAD-MKSOFT provider: "Intel",RAD-MKSOFT catalog: "e1000325.cat",RAD-MKSOFT devices: nil, Chapter 7. Common deployment features 343
  • RAD-MKSOFT __devices: "inf_DeviceType", RAD-MKSOFT devnames: { "Intel(R) PRO/1000 Gigabit Server Adapter", RAD-MKSOFT "Netfinity Gigabit Ethernet SX Adapter", RAD-MKSOFT "Intel(R) PRO/1000 F Server Adapter", RAD-MKSOFT "Gigabit Ethernet SX Server Adapter", RAD-MKSOFT "Gigabit Ethernet Server Adapter", RAD-MKSOFT "Intel(R) PRO/1000 T Server Adapter", RAD-MKSOFT "Intel(R) PRO/1000 XT Server Adapter", RAD-MKSOFT "Intel(R) PRO/1000 XT Desktop Adapter", RAD-MKSOFT "iSeries 1000/100/10 Ethernet Adapter", RAD-MKSOFT "Intel(R) PRO/1000 XT Network Connection", RAD-MKSOFT "Intel(R) PRO/1000 XF Server Adapter", RAD-MKSOFT "iSeries Gigabit Ethernet Adapter", RAD-MKSOFT "Intel(R) PRO/1000 XF Network Connection", RAD-MKSOFT "Intel(R) 82544GC Based Network Connection", RAD-MKSOFT "Intel(R) PRO/1000 T Desktop Adapter", RAD-MKSOFT "Intel(R) PRO/1000 T Network Connection", RAD-MKSOFT "Intel(R) PRO/1000 MT Desktop Adapter", RAD-MKSOFT "Intel(R) PRO/1000 MT Network Connection", RAD-MKSOFT "Intel(R) PRO/1000 MT Mobile Connection", RAD-MKSOFT "Intel(R) PRO/1000 MT Desktop Connection", RAD-MKSOFT "Intel(R) PRO/1000 MT Server Adapter", RAD-MKSOFT "Intel(R) PRO/1000 MF Server Adapter", RAD-MKSOFT "Intel(R) PRO/1000 MF Server Adapter (LX)", RAD-MKSOFT "Intel(R) PRO/1000 MT Dual Port Server Adapter", RAD-MKSOFT "Intel(R) PRO/1000 MT Dual Port Network Connection", RAD-MKSOFT "Intel(R) PRO/1000 MF Dual Port Server Adapter", RAD-MKSOFT "Intel(R) PRO/1000 MF Dual Port Network Connection", RAD-MKSOFT "Intel(R) PRO/1000 MT Network Adapter", RAD-MKSOFT "Intel(R) PRO/1000 CT Desktop Connection", RAD-MKSOFT "Intel(R) PRO/1000 CT Network Connect