Front cover
Architecting a Highly Efficient Image
Management System with Tivoli
Provisioning Manager for OS Deployment
Guidelines for selecting an image
management solution
Architectural considerations for
the TPM for OS deployment
Deployment scenarios
and case studies
Vasfi Gucer
Scott Kay
ibm.com/redbooks
Redpaper
International Technical Support Organization
Architecting a Highly Efficient Image Management
System with Tivoli Provisioning Manager for OS
Deployment
March 2007
REDP-4294-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page v.
First Edition (March 2007)
This edition applies to IBM Tivoli Provisioning Manager Version 5.1.
© Copyright International Business Machines Corporation 2007. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
The team that wrote this IBM Redpaper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Device configuration life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Why Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 A deployment project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Requirements for a tool to assist the deployment effort . . . . . . . . . . . . . . 10
1.3.1 Time to value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 Resource and maintenance efficiency . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Common OS deployment scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1 Rollout of new desktop hardware and SOE . . . . . . . . . . . . . . . . . . . 14
1.4.2 Rebuild of a previously deployed user workstation . . . . . . . . . . . . . . 14
1.4.3 Upgrade of hardware and subsequent Vista install. . . . . . . . . . . . . . 15
Chapter 2. Architecture and deployment scenarios . . . . . . . . . . . . . . . . . 17
2.1 Tivoli Provisioning Manager for OS Deployment features. . . . . . . . . . . . . 18
2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Small site architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.2.3 Enterprise architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
© Copyright IBM Corp. 2007. All rights reserved.
iii
iv
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2007. All rights reserved.
v
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX®
DB2®
IBM®
Redbooks™
Redbooks (logo)
Tivoli®
™
The following terms are trademarks of other companies:
Solaris, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States,
other countries, or both.
Active Directory, Aero, BitLocker, Microsoft, Windows Vista, Windows, and the Windows logo are trademarks
of Microsoft Corporation in the United States, other countries, or both.
Xeon, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel
Corporation or its subsidiaries in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
vi
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Preface
Tivoli® Provisioning Manager for OS Deployment provisions operating systems
and applications for computers using the Pre-boot eXecution Environment (PXE)
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, SMB, or larger accounts.
In this IBM® Redpaper, we discuss how to design and implement a highly
effective image management solution for small, medium, and enterprise
accounts, taking network bandwidth limitations and large OS image sizes into
consideration. We also cover the considerations for choosing an image
management solution and the benefits of implementing such an environment.
Note that this IBM Redpaper is more geared to IT Architects. For a full discussion
of Tivoli Provisioning Manager for OS Deployment, including installation,
customization and other product integrations, you can refer to Deployment Guide
Series: Tivoli Provisioning Manager for OS Deployment V5.1, SG24-7397.
The team that wrote this IBM Redpaper
This IBM Redpaper 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 has
worked on various Tivoli customer projects as a Systems Architect in Turkey and
the United States. Vasfi is also a Certified Tivoli Consultant.
Scott Kay is an Advisory Technical Specialist working for 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, and systems management. After joining
IBM in 1999, Scott worked in roles all directly related to the Tivoli suite of
products in Global Services, Tivoli Professional services, and, finally, in his
current pre-sales role in the Software Group.
© Copyright IBM Corp. 2007. All rights reserved.
vii
Thanks to the following people for their contributions to this project:
Arzu Gucer, Wade Wallace
International Technical Support Organization, Austin Center
Dennis R Goetz, Peter Greulich, Hakan Thyr
IBM USA
David Clerc and Marc Vuilleumier Stueckelberg
IBM Switzerland
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbooks™
publication dealing with specific products or solutions, while getting hands-on
experience with leading-edge technologies. You will have the opportunity to team
with IBM technical professionals, Business Partners, and Clients.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you will develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our IBM Redpapers to be as helpful as possible. Send us your
comments about this IBM Redpaper or other Redbooks in one of the following
ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an e-mail to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
viii
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Preface
ix
x
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
1
Chapter 1.
Introduction
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 can be found in 1.1, “Device configuration life cycle”
on page 2.
We look at business needs and the sort of IT changes that are coming that would
justify an investment in a technology such as Tivoli Provisioning Manager for OS
Deployment. We also look at how this technology would reduce costs associated
with deployment and redeployment of operating systems. This can be found in
1.2, “Business requirements” on page 6.
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 can be found in 1.4, “Common OS deployment
scenarios” on page 13.
© Copyright IBM Corp. 2007. All rights reserved.
1
1.1 Device configuration life cycle
Every facet of IT these days seems to have a life cycle management strategy,
process, or best practice. Asset life cycle management, software life cycle
management, user account life cycle management, and storage life cycle
management, to name 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 have been 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
Application and Data
Software distribution
Asset and Inventory Management
Security Configuration
Software License
and usage
Management
Remote Control
Software Maintenance
and Patch Management
Reporting for Critical Decision Making
Figure 1-1 Tasks and activities within the device configuration life cycle
2
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
There are many product suites on the market today that can enable or automate
these tasks and a few that claim to do it all. Most organizations, however, already
have mature tools and processes in place for many of the tasks in the life cycle
and are not about to rip out and replace their existing solution unless there is a
very good business case to do so. This is where Tivoli Provisioning Manager for
OS Deployment offers an excellent opportunity. Tivoli Provisioning Manager for
OS Deployment is a stand-alone product that offers significant integration
capability, so much so that it has already been integrated with Tivoli Provisioning
Manager, Tivoli Provisioning Manager for Software, and will soon be integrated
with IBM Director.
The core capability of Tivoli Provisioning Manager for OS Deployment is the
ability to intelligently automate the deployment of operating systems. This
capability extends from the many flavors of Microsoft® Windows®, through
SUSE and Red Hat Linux® to Sun™ Solaris™. The deployment of an operating
system is the one item in the configuration life cycle that every single computer
will definitely receive at least once and potentially more often during its working
life. This is shown in the context of the Device Configuration life cycle in
Figure 1-2
Tasks and Activities within the Device Configuration Lifecycle
TIVOLI PROVISIONING MANAGER
FOR OS DEPLOYMENT
FULL AUTOMATION
BARE METAL OS DEPLOYMENT
Backup and Restore
Application and Data
Software distribution
Asset and Inventory Management
Security Configuration
Software License
and usage
Management
Remote Control
Software Maintenance
and Patch Management
Reporting for Critical Decision Making
Figure 1-2 Tivoli Provisioning Manager for Operating Systems role in the Configuration
life cycle
Chapter 1. Introduction
3
Once 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 will become 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 is in the
areas of:
– Image storage space: Due to the ability Tivoli Provisioning Manager for OS
Deployment has to modify an image and add drivers through driver
injection on the fly during an image deployment, only one image and a
collection of driver packages will 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 would require a site visit by a technical staff member.
The savings that can be made here are harder to quantify, but easy to identify.
Any time a user is taken away from their core responsibility to help fix a
problem is a business cost. In an organization large enough, it is easy for
these distractions to add up to lost man-days on a daily basis due to users
being involved in helping with a fix.
Tivoli Provisioning Manager for OS Deployment also touches other parts of the
device configuration life cycle with functionality that enables the core OS
deployment functionality, as can be seen in Figure 1-3 on page 5
4
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Tasks and Activities within the Device Configuration Lifecycle
TIVOLI PROVISIONING MANAGER
FOR OS DEPLOYMENT
DEPLOYMENT ENABLING FUNCTIONALITY
Bare Metal OS Deployment
Backup and Restore
Application and Data
SOFTWARE DISTRIBUTION
ASSET AND INVENTORY
MANAGEMENT
Security Configuration
Software License
and usage
Management
Remote Control
Software Maintenance
and Patch Management
Reporting for Critical Decision Making
Figure 1-3 Deployment enabling functionality of Tivoli Provisioning Manager for OS
Deployment
Deployment enabling functionality: Tivoli Provisioning Manager for OS
Deployment’s core function is its ability to deploy operating systems. Included in
the product are some other capabilities that enable this core function. These
capabilities are:
1. 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 once the operating system has
started.
2. Inventory
When Tivoli Provisioning Manager for OS Deployment boots a computer
using PXE, it automatically scans the computer and stores this data in its
database. Having the results of these scans available allows Tivoli
Provisioning Manager for OS Deployment to make decisions based on this
data about which drivers to inject during OS deployment and which software
to deploy after OS deployment.
Chapter 1. Introduction
5
Coupled with the enabling capabilities, Tivoli Provisioning Manager for OS
Deployment is able to then intelligently install a full SOE in an automated
manner, completely automating the first task in the device configuration life cycle,
that is, bare metal OS deployment.
1.2 Business requirements
At a high level, business requirements are simple: help save money to improve
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
and 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 for 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. Recent surveys have indicated that many organizations are
expecting to make a move towards Vista within a year, but they also showed that
the larger the organization, the higher the probability that this would occur.
This significant commitment in time and expense is driven by a variety of factors
which include much needed features introduced in Vista, and the realities of
waning support for older versions of Windows.
While enhancements in user experience like Vista's Aero™ Glass interface have
monopolized the marketing spotlight, it is enhancements under the covers that
are motivating enterprise customers to upgrade. Vista introduces a new
developer platform, .NET Framework 3.0, which will enable faster development of
applications that will have better interfaces, better integration with other
applications, and better code in general. The .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), which
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
6
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Trustworthy Computing Initiative. Immediate beneficial security enhancements
include User Account Control, which 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 will protect 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 for which the enterprise has been waiting.
Beyond the innovations Vista offers as a motivation to upgrade, there is also the
fact that older versions of Windows are becoming less supportable. Analysts
converge around 30% as the number of enterprise users still on pre-XP versions
of Windows. 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 these surveys are to be believed, the question of when this upgrade will occur
is in the next 12-18 months. 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 would be 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:
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 be able to
quantify them all, and prioritize and plan with certainty. Being presented with
10 untested applications just before the rollout would have an unpleasant
impact on 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 have to have an explicit effort
applied to make them compatible. This project phase has the potential to be
the most time consuming and least satisfying, as old but important
applications may not work in Vista and may have to be worked around.
Chapter 1. Introduction
7
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 will be 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 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, and more
generic base images to store and deploy, thus saving disk space and
network bandwidth, and subsequent changes to an image or core
application results in far less image regeneration. End-to-end deployment
is now slower and requires a software distribution system and scripting to
complete. Actual bytes deployed will likely be more than in thick images
because of duplication of files in the application install and OS install,
although the install is spread out over a longer period of time. Note that not
having all applications deployed at first boot introduces security risks.
– Hybrid images offer the best of thick and thin images without the
disadvantages. Advanced hybrid imaging systems separate drivers and
applications from OS images and store them in a file-based repository. At
deploy time, the correct drivers are automatically selected and injected
into the image, the correct updates and core applications are loaded into
the image, and the resulting image is deployed to the target, all before first
boot. This allows an organization to maintain as few as one universal
image that automatically adapts to each target at deploy time when the
minimum number of files possible is deployed over the network. The result
is minimal disk space, minimal network bandwidth, and a system that
allows modification to driver or application configuration without the need
to generate and catalogue a new image. The most advanced hybrid
imaging systems go a step further by providing a policy-based
configuration capability. This allows the image to be adapted by global
8
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
policies as well as physical attributes of the target. For example, a policy
such as "deploy ThinkVantage Access Connection on Lenovo mobile
computers only" would ensure that redundant software is not deployed on
other brand of mobile computer. The challenge for the enterprise is that
very few image management systems on the market support this
advanced form of imaging.
4. 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.
Chapter 1. Introduction
9
1.3 Requirements for a tool to assist the deployment
effort
The following is a list of criteria that can be used in the assessment of a
deployment tool.
1.3.1 Time to value
How long it takes to start getting significant improvements in efficiency in your
migration process is key to the overall performance of your image management
system. Many systems management products either remain on a shelf or are
never implemented to their full potential because of the complexity of their
installation and configuration. Consider the following aspects of the system's
Time to Value:
1. How long does it take to install the product and start using it in your migration
planning process? Will installation take 30 minutes? Or 30 days?
2. Is the system an integrated single vendor solution that provides fully
automated end-to-end deployment of desktops from Wake-on-LAN, to BIOS
configuration, RAID configuration, disk partitioning, OS/driver/application
deployment, offline servicing, and 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 third-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, native PXE, native configuration database, and so on)? 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
10
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
dramatically reduces the time required to configure the images for large and
diverse populations. Without this capability, each target image would have to
be manually configured.
Note: This capability is only possible if the system supports advanced hybrid
images.
7. Does the system support advanced hybrid images allowing you to start
deploying diverse systems after creating a single universal OS image? Or
does the product require that you create many specific thick images before
you can start testing against a diverse community of targets? Or does the
product require that you also implement a software distribution system before
you can start deploying applications on top of thin images?
1.3.2 Resource and maintenance efficiency
These selection criteria assess the image management system's impact on your
systems 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 in 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?
Chapter 1. Introduction
11
4. Does the system support distributed, automatically synchronized deployment
servers that can sit in distributed network segments closer to specific groups
of targets? Does the system provide this functionality in the base product
without requiring an additional investment in product license and
implementation effort? This capability can dramatically reduce the
performance impact and capacity required at gateways, routers, and over
wide area networks.
1.3.3 Flexibility
As your choice of a 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, or 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, and so on) 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
practices 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; however in others, the OS vendor does know best.
4. Will the product integrate easily into any systems management ecosystem,
seamlessly providing an image management foundation to any vendor's
holistic provisioning solution? Or does the product restrict its interfaces in an
attempt to force you to build on its foundation with only the same vendor's
systems management portfolio?
5. Does the vendor that supplies the product also provide a portfolio of
integrated provisioning and systems management products if you are looking
for a simple path to increase the sophistication of your automation
infrastructure?
12
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
1.3.4 Security
Mitigating security risks is a top three budget item for most enterprise IT
organizations. Introducing new security risks with the image management
system will result 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 has been architected to minimize the
security exposures it introduces:
1. Has the system implemented Option-43 of the PXE specification that prevents
malicious PXE Server impersonation on your network by forcing explicit
identification of the PXE server network address? If not, an intruder that gets
access to any server on your network could deploy code that impersonates a
PXE server on your network, giving the intruder the ability to alter your
desktop configurations.
2. Does the product disallow a user break of the deployment process at the
target keyboard? If not, someone with access to the target during the
deployment could gain administrator level privileges on your network.
3. Does the product support Offline Servicing for Vista? Offline servicing allows
security updates and configuration changes to be applied to the target after
the OS and core application deployment, but before the first boot. If the
product does not support this Microsoft best practice function, the target is
exposed to many forms of intrusion and malware between first boot and the
application of the security updates.
4. Has the product implemented an encrypted transport protocol that prevents
either reading or altering the image bit stream while it is being deployed over
your network? Keep in mind, depending on your applications, these bit
streams could contain sensitive data or passwords. Many products just
support Server Message Block (SMB) or HTTP transport protocols that leave
the data exposed to malicious intruders or applications. SMB and HTTP also
require the creation of a user in the network and the storage of that user's
password on the boot media, which is an unnecessary security exposure.
1.4 Common OS deployment scenarios
The following 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 has been 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.
Chapter 1. Introduction
13
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 mobile computers of two
different specifications.
The hardware supplier is contracted to supply the workstations directly to their
final destination across three continents into 25 sites.
The organization has spent the previous 12 months developing their Vista SOE,
their deployment methodology, and deploying Tivoli Provisioning Manager for OS
Deployment. The solution developed uses a universal system profile. The
universal system profile allows them to have one image that can be deployed to
every desktop computer and mobile computer. When the computers first PXE
boot and contact Tivoli Provisioning Manager for OS Deployment, an inventory is
taken of the 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 would be different than
those required by a mobile computer computer. Based on the model number of
the computer and the PCI, Tivoli Provisioning Manager for OS Deployment can
inject the necessary drivers.
The deployment process for desktop computers is as follows:
򐂰 The vendor ships the computers to the site as per the deployment schedule.
򐂰 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 4 GB image deployment over a 100 Mbps LAN to 30 workstations
completes in 30 minutes.
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 mobile computer 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.
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
14
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
with some file corruption. The help desk consultant spends 15 minutes with the
user trying to determine what the problem with the workstation is. It is apparent
that there is a problem, but a diagnosis is eluding them. The help desk consultant
decides that a workstation rebuild is the best way forward.
Tivoli Provisioning Manager for OS Deployment had been previously rolled out
across the enterprise a few months ago. 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, among other things, the ability to reboot a
computer and 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 user’s 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 100 Mbps available. The 4 GB 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 has 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 512 MB 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.
The upgrade process is as follows:
Chapter 1. Introduction
15
򐂰 As all the workstations are already defined within Tivoli Provisioning Manager
for OS Deployment, it is a simple task of binding the new Vista profile and the
rollout deployment scheme to all the workstations. This is done.
򐂰 After each computer is opened and has its RAM upgraded, the computer is
rebooted and F12 is pressed to force a network boot.
򐂰 As the computer is bound to the SOE, the computer joins a rolling
non-synchronized multicast deployment scheme. This scheme ensures
maximum efficiency of concurrent data transfer but without the necessity to
synchronize computers. The deployment is completed overnight as planned.
16
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
2
Chapter 2.
Architecture and
deployment scenarios
This chapter will present two case studies for the implementation of Tivoli
Provisioning Manager for OS Deployment: first for a small implementation on a
single LAN, and second for 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 18
򐂰 “Architecture” on page 21
© Copyright IBM Corp. 2007. All rights reserved.
17
2.1 Tivoli Provisioning Manager for OS Deployment
features
Here we list the major features of Tivoli Provisioning Manager for OS Deployment
and a short description of those 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
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,
which 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 deploy a profile.
18
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
򐂰 Unattended setup
Tivoli Provisioning Manager for OS Deployment supports the unattended
setup mode of installation. In this feature, all of the parameters that need to be
provided to the installer during the OS installation are predefined in the Tivoli
Provisioning Manager for OS Deployment server and fed to the installer
during the installation. This type of installation is best where a one off
installation is going to be made or where installation to a number of different
hardware types would require an investment of time to build a master image
and all of the appropriate drivers and or application packages.
򐂰 Unicast and multicast image deployment
In Tivoli Provisioning Manager for OS Deployment, profiles, or what is being
deployed, are defined separately to how the profile is to be deployed. How the
profile is to be deployed is defined in what is known as a deployment scheme.
It is in the deployment scheme that you can define the communication method
between the server and client. This can be unicast or multicast. Generally,
individual workstation and server builds would be done using unicast, while
builds of batches of workstations would use multicast for the time and network
bandwidth savings that it offers.
򐂰 Adjustable network bandwidth utilization during build
Deployment Schemes also offer the ability to limit the amount of network
bandwidth that is used during a deployment. This is very useful when a
deployment is being executed over a LAN during the business day. An
unlimited deployment would have the capability to really slow the network
segment down as it could potentially use all available bandwidth; however, if
you limited the bandwidth to 50 Mbps on a 100Mbps LAN, it could only ever
absorb half the available bandwidth.
򐂰 Highly efficient image storage
By using an MD5 algorithm to individually identify each file being stored in the
image repository, it is possible to eliminate the need to store duplicates of any
file. What this means is that one Windows XP image may take 3 GB of
storage space, but two variations of an XP image could take less than 4 GB.
This efficiency of storage also translates to less image data needing to be
replicated between servers in larger implementations.
򐂰 Build from DVD
In some instances, a workstation that needs to be built may be at the end of a
64 Kbps link, or worse. Attempting to install a 4 GB image in a case like this
would be impractical; the data transfer, if all went well, would take more than
seven days. In an instance like this one, it is possible to cut a DVD of the
image and deployment scheme, ship it to the site, then boot from that DVD
and deploy the image from the DVD.
Chapter 2. Architecture and deployment scenarios
19
򐂰 Boot from CD/DVD
If the network card in a particular target system does not support PXE boot,
or PXE is not allowed on a network, it is possible to build a boot CD or DVD on
the Tivoli Provisioning Manager for OS Deployment server, and use it to boot
the target computer and connect it to the Tivoli Provisioning Manager for OS
Deployment server to have an image deployed.
򐂰 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 situation, Tivoli Provisioning Manager for OS
Deployment comes with two methods to replicate data between servers:
a. Scheduled, bandwidth controlled replication
This option allows you to set up a replication schedule between servers
and dictate the maximum bandwidth that can be used by that replication.
b. Command-line export utilities
Through the use of command-line utilities, it is possible to produce
difference 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 burned 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.
20
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
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 would fit 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 should be
given consideration when designing a Tivoli Provisioning Manager for OS
Deployment implementation. Many of the items are quite obvious but warrant
discussion and further explanation, while others are less obvious and may assist
a designer in reaching an appropriate design. While the following list is quite
comprehensive, it should not be considered the definitive list of considerations,
as every organization has its own set of idiosyncrasies to take into account.
Unattended setup
An unattended setup of a Windows or Linux operating system entails the
provision of all the parameters required in the setup of the operating system by
the Tivoli Provisioning Manager for OS Deployment. Unattended setup is a more
time consuming method of deploying an operating system and cannot be used
on the same scale that cloning can. However, it is the easiest type of deployment
profile to setup. All activities take place on the server through the Web interface.
An advantage of an unattended setup profile is that it is a more generic
installation, as the setup program detects the hardware and peripherals present
and, if a driver is available, installs it. The important task that the deployer has is
to ensure that all the necessary drivers are available.
An unattended setup can be a good way to build an initial system for cloning. It is
also very good for building systems in an environment where the hardware has
large differences.
Chapter 2. Architecture and deployment scenarios
21
Figure 2-1 shows the potential inputs to an unattended setup. This instance
includes the original files, parameters such as the license key, host name,
administrator account details, and the domain to join. It also includes a driver
package and a software package.
Unattended
install
Parameters
Driver
package
Driver
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 setup than an
unattended operating system setup. The process to clone a machine is as
follows:
You need to start with a reference machine that is representative of the different
systems to which you are going to deploy.
Clean the machine; by this, we mean empty the recycle bin, disconnect the
network drives and printers, close all applications, and delete all temporary files
and caches.
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
22
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
instance of the operating system. When the workstation is booted for the first
time after deployment, Tivoli Provisioning Manager for OS Deployment will
supply all the parameters required to complete the mini setup and give this
instance of the operating system its personality.
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.
As you can see, there are more steps involved in preparing a cloned image, but
when it comes to the deployment of the image, it is much faster and can be
deployed concurrently to many more systems.
Figure 2-2 shows the cloning process. The “snapshot” of the reference PC is
copied to all the computers being built, along with parameters, such as the
license key, host name, administrator account details, and the domain to join. It
also includes two driver packages and a software package to further customize
the installation.
Reference PC
Parameters
Driver
Package
Software
package
Driver
Package
Snapshot is combined
with parameters and
packages at build time
to rapidly apply a
personality to multiple
computers
concurrently.
Tivoli Provisioning
Manager for OS
Deployment server takes
a "snapshot" of the
reference PC.
Figure 2-2 Cloned systems
Chapter 2. Architecture and deployment scenarios
23
Universal system profile
A universal system profile is a cloned image that has been prepared with all
drivers for disk types and hardware abstraction layer (HAL) variants that are used
in the organization, so that one cloned image can be sent to many hardware
types and the mini setup will be able to cater to the changes necessary for the
image to work.
Figure 2-3 shows a universal system profile. With the addition of the 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
Previously created
snapshot
Software
Software
Software
Driver
Packages
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,
the video card, and so on, but the difference is enough to make the clone image
captured from one computer model to not work on the other. To fix this problem,
you could always capture an image from the second model and build rules to
ensure that the 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.
24
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
When the package is installed, the files are automatically copied into the \Drivers
directory on the target system, generally after the OS files have been deployed.
When the system boots up and sysprep runs, the driver for the hardware will be
installed by the operating system.
In some instances, it may be desirable to install the driver package after one of
the system reboots or in a specific order to avoid software conflicts. These
characteristics are all controllable and set up in the driver package creation
wizard.
Using this functionality, it is possible to just add driver packages to images as a
vendor’s hardware evolves over time.
Software packages
Like driver packages, software packages are all the files required to deploy a
software application bundled up for addition to a deployment; however, the
difference between the two is that a software package is executed and the
software is installed, as opposed to a driver package, which places the files into
the file system for installation by the operating system. Tivoli Provisioning
Manager for OS Deployment has the capability to install the following:
򐂰 A Windows application, using the Windows Installer Microsoft Installer
Package (MSI)
򐂰 A Linux application, using Red Hat Package Management (RPM)
򐂰 A Solaris application, using PKGADD; and
򐂰 A custom action on the target computer. These actions include:
– Copy and run a single file.
– Execute a command.
– Modify a Windows registry.
– Create or modify a Windows INI file.
– Copy a single text file.
Using this capability, it is possible to start to build a SOE by first deploying an
operating system and then installing software and customizing that operating
system.
It is important at this stage to point out that Tivoli Provisioning Manager for OS
Deployment is not a software distribution tool like Tivoli Configuration Manager,
Tivoli Provisioning Manager for Software, or Tivoli Provisioning Manager. It lacks
many of the features that make up a true software distribution tool.
Chapter 2. Architecture and deployment scenarios
25
Binding
In Tivoli Provisioning Manager for OS Deployment, the term binding refers to an
association made between two components within the system. It is possible to
bind a profile to a host, a software package to a host, or a software package to a
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 will, by default, automatically
start 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.
Host names
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 typing a name into the Web console once a computer has registered
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 would be unacceptable.
2. Import a list of host names. 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 in
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
window.
3. Automatic generation of 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 building it into the host name according
to a template. This means you could incorporate all or part of the computer’s
serial number or asset number into its host name.
4. Let Tivoli Provisioning Manager for OS Deployment decide. Tivoli
Provisioning Manager for OS Deployment will assign a host name.
26
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
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 are present during
the deployment and redeployment of computers, Tivoli Provisioning Manager for
OS 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 a
staging area, 50 computers are built concurrently using a multicast protocol and
at the conclusion of the deployment, the computers are shut down before the
sysprep is run, because the organization has decided that they want the
computer to join a domain when it is on site. While rebuilding a workstation out
on a branch network would use a unicast protocol and the computer would
reboot ready for the user to log on when the deployment completed, this
redeployment of the profile required absolutely no action from the user apart from
the removal of their hands from the keyboard. Both of these examples are
deployment schemes 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 level of interactivity required during a deployment. Interaction ranges
from none, where hosts are already defined in the system (prompt the first
time a system is to be deployed but not every subsequent deployment, and
prompt every time a system is to be deployed or redeployed).
򐂰 When a profile is being deployed, Tivoli Provisioning Manager for OS
Deployment will, by default, compare the computer model that the profile was
created on with that 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 (for when you would like an operator to decide whether
it is okay 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 window 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 two stages to this: first,
when all the files have been 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
Chapter 2. Architecture and deployment scenarios
27
occur when the computer reaches its final destination. You could have
sysprep run interactively, which could be useful, for example, if the time zone
of 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 would give you the opportunity to move the
computer to the user environment for final customization, or joining of a
domain, and when sysprep has completed and the computer is ready for use.
The second stage, after the points listed above have occurred, you can
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 will decrease
rapidly. A unicast is effectively a private conversation between two
computers. If the profile to be deployed was 2 GB, the Tivoli Provisioning
Manager for OS Deployment server has to serve up to 2 GB of data and
that 2 GB would have to traverse your network. If you were deploying three
computers concurrently using the same profile, the server would have to
maintain three sessions doing the same thing, queue and process the 2
GB three times, and the resultant 6 GB would have to traverse the network
through one network card. Now with a reasonable sort of server on a
gigabit network, that is probably not a big deal, but on a 10 Mb network,
that would mean at least 1 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 29 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 would during a single build.
28
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
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 4
Figure 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 that 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 selects 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. Once the master has finished 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 they require. This process continues until all the client
computers have all required files.
So let us carry our unicast example forward into our multicast explanation
and distribute our 2 GB image to three computers. One of the computers is
of a lower performance specification than the other two. There would be a
Chapter 2. Architecture and deployment scenarios
29
2 GB transfer to the machine designated by the server as the master
client; the first slave is able to keep up with the master and therefore it
received and processed 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 2 GB 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.4 GB of data traversing the network instead of 6
GB, 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 two variants of
Multicast:
– Synchronized multicast. With this option, it is possible to have the start of
transmission delayed until a predetermined number of clients register with
the server or a timeout period is reached. Once 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 will automatically share the same bandwidth.
Figure 2-5 on page 31 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
30
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Server
The packets on the network are addressed to a group, so
all members of the group can accept the packet.
In this way, one packet can be accepted by many
computers, reducing the amount of network traffic.
Group
Group
Group
Group
Figure 2-5 Multicast
򐂰 Onsite deployment. This feature should be enabled if you wan to use the
advanced redeployment feature.
Using these various options, it is possible to cater to most deployment situations
in the most efficient way. A thorough Tivoli Provisioning Manager for OS
Deployment design would include specifications for the deployment schemes to
be used in the final implementation. These specifications would also highlight the
necessity for things like multicast support and the level of interaction that is
expected with each deployment type.
Image replication
It is important to have a good understanding of how file replication in Tivoli
Provisioning Manager for OS Deployment works, so that the effect it will have on
a production network can be appreciated.
How replication works
When a profile is captured or built with the Tivoli Provisioning Manager for OS
Deployment server, the files undergo the following process: as files are sent to
the server, they are uniquely identified using an MD5 (Message Digest 5)
algorithm. Having identified the file, the process then determines whether there is
another copy of the file already in storage on the server. If there is, the existing
Chapter 2. Architecture and deployment scenarios
31
file is referenced in the new profile and if not, the process stores the file in a 128
MB 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, using the built-in file
replication service or by manually generating change files at the command line
and using another tool to move these files around the network.
Built-in file replication service
In a multi-tiered implementation, one server will be designated as the master
server. This would usually be 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
window. 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 33.
32
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Master
Server
11
12
1
2
10
3
9
3
4
8
7
6
5
.RAD File
4
.RAD File
TO
C
Re
q'd
lis
t
1
.RAD File
file
s
5
2
1 Table of Contents files sent to slave server at a scheduled time.
Slave
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 The .RAD file is sent to the slave server.
5 Slave server checks the .RAD file and then incorporates its contents into its repository.
Figure 2-6 Tivoli Provisioning Manager for OS Deployment replication data flow
In a multi-tiered environment, the replication setup has to be given some
consideration, as it is done on a schedule. It is important that enough time is
given between scheduled instances for the replication to complete. In the
instance of a three tiered architecture, each predecessor must be completed
prior to the successor starting. You must factor the bandwidth limitation you place
on the replication into this equation.
Command-line method
Tivoli Provisioning Manager for OS Deployment offers a command-line interface
called RbAgent. RbAgent can be run from any workstation that has connectivity
to the Tivoli Provisioning Manager for OS Deployment server. When executed,
the RbAgent command connects back to the Tivoli Provisioning Manager for OS
Deployment server, and assuming the appropriate .PAK file is present in the, by
default, C:\Program Files\Common Files\IBM Tivoli\packages directory, runs the
command.
This command-line capability offers excellent integration opportunities with
preexisting tools for file transfer and configuration management, such as those
Chapter 2. Architecture and deployment scenarios
33
already incorporated into IBM Tivoli Configuration Manager V4.2.3 FP2, IBM
Tivoli Provisioning Manager, and IBM Provisioning Manager for Software.
To synchronize servers from the command line, you need to first download the
file sync.pak from the IBM OPAL web site at
http://www.ibm.com/software/tivoli/features/it-serv-mgmt/opal.html,
copy that file into the directory stated above, then stop and start the Rembo
Server service. This will make the commands implemented in sync.pak available
to RbAgent.
Then 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, difference files
containing all the file repository changes that need to be sent to a “slave” server
can be generated. These difference 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:\TPMFOSFiles\import\Auto 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 and when one is found it will reassemble it if it is a series of .DAT
files, and check it for consistency and then if all is okay, it will be given a .OK
extension and the server will incorporate the content of the file into the shared
repository, making that content available for use in that server.
Important: While the command-line method of repository synchronization
does give control of the replication process back to the user, it must be noted
that:
򐂰 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 would
need to be incorporated into the overall replication process.
Profile migration
The separation of development, test, and production environments is a long
standing IT best practice. Tivoli Provisioning Manager for OS Deployment
incorporates functions that allow for the export and import of developed profiles,
software packages, and deployment schemes. This allows these objects to be
moved between environments easily and quickly.
34
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Export
To export a profile, software package, or deployment scheme, go to the OS
Deployment window and select one of the system profiles window, the software
deployments window, or the deployment scheme window. At the bottom of the
window, select RAD Export; this will start the RAD Export Wizard. You will be
guided through a series of windows allowing you to select the items you wish to
export. The server will analyze the objects you wish to export and approximate
the size of the export file and give you three options on how to deal with the file:
򐂰 You could download it directly to the computer from which you were accessing
the Tivoli Provisioning Manager for OS Deployment server. This would allow
you to use it as a staging point.;
򐂰 Export it to a directory on the Tivoli Provisioning Manager for OS Deployment
server. This may be the option you use if you had physically separate
environments and you needed 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 was 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
host names. You must always use an explicit IP address.
Import
At the importation end, it is almost a reverse of the export.
Navigate to the OS Deployment window, and then select one of the system
profiles window, the software deployments window, or the deployment scheme
window. At the bottom of that window, select RAD Import. You will be presented
with three options for the location of the .RAD file for import:
򐂰 The local computer from which you are working.
򐂰 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.
Whichever option you choose, the next step is to identify the .RAD file at the
location you selected for importation.
Chapter 2. Architecture and deployment scenarios
35
Tivoli Provisioning Manager for OS Deployment will then analyze the file and
import the parts of it that it requires, bearing in mind that it will only import files
that are not already stored on the server.
Tip: Right-clicking the item to be exported will let you access the export and
import functions. You can also access those functions through 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,
and if that is not available, it tries for other removable devices. 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 to change the boot order is to press the F12 key (on many
computers) at a specific time during the boot process to go 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.
Once the initial build of a computer has been completed, you have some options
about how much Tivoli Provisioning Manager for OS Deployment gets involved in
the boot process.
Generally, computers are set to boot from their hard drive after a deployment.
With Tivoli Provisioning Manager for OS Deployment, it is possible to boot from
the hard drive or network, with each method having options to control bot
behavior.
Hard drive boot
Booting off the hard drive is probably the first choice and the traditional choice
made by IT departments. Should you wish to rebuild a machine at a later time
due to malfunction or upgrade, you would need to contact the user and have
them intervene in the boot process so that Tivoli Provisioning Manager for OS
Deployment could boot the machine and take control remotely. This is not ideal in
a support situation; if you want a completely hands free experience for your user,
36
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
the RbAgent could be included in the standard computer build. The inclusion of
RbAgent would allow the “Deploy Now” function within the tool to be executed
when a redeployment was needed. Under instruction from the server, RbAgent
would shut the computer down after writing a temporary master boot record
instructing the computer to boot from the network at the next boot. The computer
would reboot using the network boot method, connect to the Tivoli Provisioning
Manager for OS Deployment server, and deploy the profile using the deployment
scheme as selected by the operator, giving a fully hands free deployment.
Network boot
Another option is to set computers to boot off the network every boot and set the
action that will be taken in the Tivoli Provisioning Manager for OS Deployment
server. Possible actions include:
1. 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).
2. The computer is configured to boot on the hard disk in the console. In this
case, the computer boots on the disk.
3. 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 timeout, ask for a password, and so
on).
4. The computer has no configuration bound to it in the database. In this case, a
locked window is shown.
All of these options give you the opportunity to change the boot behavior of the
computer from the Tivoli Provisioning Manager for OS Deployment console.
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 computers
hard disk.
Chapter 2. Architecture and deployment scenarios
37
The real value in this feature is for computers that fall into 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 every time the computer is rebooted.
Here 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 has finished 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 possible actions. Those
actions are:
– 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 timeout.
With Redeployment enabled in a school library or in an Internet cafe, a possible
scenario would be that at the end of every day all the computers are shut down.
Every morning when the computers are booted, they would wait 10 seconds and
then start doing a quick restore as the default option is automatically selected.
This would ensure that a fresh environment is available to the users everyday,
devoid of adware, viruses, or caches containing inappropriate material.
38
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Server specification
The size and configuration of a Tivoli Provisioning Manager for OS Deployment
server should be decided after taking a number of factors into consideration.
First, the number of hosts you wish to define within the server is one factor. Once
you reach 1-2000 hosts, the GUI starts to reach the limits of its navigability and
becomes a practical limitation. It just takes too long to scroll through the host list.
That said, if you used RbAgent and set the implementation up so that
distributions were all triggered from the client interface, this would not be an
issue and scalability up to 5000 hosts on one database is easily achievable.
Where an organization’s computers exceed 2000, it would be wise to start
splitting the database across servers. You would still replicate all the profiles and
deployment schemes. This scenario is discussed in 2.2.3, “Enterprise
architecture” on page 52”.
Second, you need to take into consideration the amount of work the server will
be doing. If the plan is to concurrently deploy multiple different profiles using a
unicast deployment schemes on an ongoing basis (a high I/O requirement), it will
be necessary to ensure a disk subsystem is capable of serving up this level of
data. This could mean using a RAID array, or, depending on the requirements, a
channel attached SAN (storage area network) solution. This type of solution
would probably only be required on a site where a large scale centralized build
LAN was being heavily utilized.
Being able to serve up data out of a disk subsystem is one thing; you also need
to be able to get that data onto the network. You may wish to consider multiple
NICs (network interface card) on a switched network in our extreme instance
above, but also a high speed LAN, such as 100 Mb or 1Gb, for maximum transfer
speed.
Third, memory. The minimum specification for a Tivoli Provisioning Manager for
OS Deployment server is 1GB of RAM. Depending on the number of users and
the number of concurrent builds being undertaken, extra RAM would be prudent.
During a computer build, RAM usage can reach 500 MB, as the server
assembles and queues the files required. Therefore, how the server is used, that
is, the number of concurrent build sessions, will dictate the memory requirement.
A multiuser RDBMS instead of the built-in Access database will also increase the
memory requirement by the amount recommended by the RDBMS vendor.
Processors: The minimum specification for a Tivoli Provisioning Manager for OS
Deployment server is dual Xeon® 1 GHz processors. The server is multithreaded
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.
Chapter 2. Architecture and deployment scenarios
39
When specifying a build server for a deployment project, you need to bear 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 on groups of computers
with similar performance, good and appropriate network infrastructure, and
well-built and considered profiles.
PXE
Preboot eXecution Environment (PXE) 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 41.
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:\ProgramFiles\commonfiles\IBMtivoli\Rbagent.exe) and enter:
rbagent.exe -s <host_ip_address>:<host_password> rad-mkbootcd
<full_path_to_boot_iso> <host_ip_address> <host_password>
Where:
host_ip_address
IP Address of the Tivoli Provisioning Manager for OS
Deployment Server.
host_password
Password for the administrative user (usually admin) on
your Tivoli Provisioning Manager for OS Deployment
Server.
full_path_to_boot_iso
The full path to the iso file you wish to create on the
machine where you run the command, including the
filename.
40
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
In Example 2-1, there are two parts:
򐂰 The first part allows the 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.
򐂰 The 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 and the IP address and password of the server
to which the boot CD will try to connect.
Example 2-1 rbagent.exe
C:\ProgramFiles\commonfiles\IBMtivoli\rbagent.exe -s 10.10.10.10:abcd
rad-mkbootcd C:\boot.iso 10.10.10.10 abcd
Once booted, the behavior of the computer will be identical to any PXE booted
system.
DVD deployment
In some instances, computers that require deployment are at remote sites, sites
serviced by communications links not suitable for large data transfers, or just with
no connectivity. These computers still form a part of an organization’s inventory
and need to be managed. In situations such as these, Tivoli Provisioning
Manager for OS Deployment has the capability to build an image onto a DVD or
spanned across several DVDs. The DVD can be transported to the computer via
mail, courier, or other means, and deployed with or without connectivity to the
Tivoli Provisioning Manager for OS Deployment server.
DHCP
The Dynamic Host Configuration Protocol (DHCP) is a mature, well documented
protocol that has been in use for many years. It is used by network attached
devices that require an IP address, but has 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, such as the addresses of various services on the
local network or 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.
Chapter 2. Architecture and deployment scenarios
41
We are particularly interested in design considerations and DHCP options 43
and 60. By default, Tivoli Provisioning Manager for OS Deployment’s installer will
make 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 both option 60 and option 43 are not 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.
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 setup, 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.
Firewalls
The following tables list the server communication ports (Table 2-1 on page 43)
and client communication ports (Table 2-2 on page 43) 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.
42
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Table 2-1 Ports required for server communication
Description
Port
Protocol
Modifiable
Purpose
Dynamic Host Configuration
Protocol (DHCP)
67
UDP
Yes
To issue IP addresses
and other network boot
information
Preboot eXecution
Environment Boot Information
Negotiation Layer (PXE BINL)
4011
UDP
Yes
To create an
environment on a
computer where a boot
program can be loaded
Trivial File Transfer Protocol
(TFTP)
69
UDP
No
(Part of PXE
specification)
Protocol used to transfer
the boot program to the
PXE environment on a
booting computer
Multicast Trivial File Transfer
Protocol (MTFTP)
4015
UDP and TCP
Disabled in
V5.1
Disabled in V5.1
Network Bootstrap Program
(NBP)
4012
UDP
Yes
For exchanging
messages with the boot
server
FILE
4013
UDP
Yes
For transferring files to a
computer in unicast
mode
Multicast (MCAST)
10000 10500
UDP Address:
239.2.0.1-239.2.
1.1
Yes
For transferring files to
multiple computers in
multicast
Table 2-2 Ports required for client communication
Description
Port
Protocol
Modifiable
Purpose
Dynamic Host Configuration
Protocol (DHCP)
68
UDP
Yes
To request and receive
an IP address and other
network boot
information
Multicast Trivial File Transfer
Protocol (MTFTP)
8500-8
510
UDP
Disabled in
V5.1
Disabled in V5.1
Multicast (MCAST)
9999
UDP
Yes
To acknowledge receipt
of Mcast packets when
designated the master
Remote control
(Web Interface Extension)
4014
UDP
Yes
To allow the TPMfOSd
server to communicate
to the Web extension
Chapter 2. Architecture and deployment scenarios
43
The ports that you need to open for Tivoli Provisioning Manager for OS
Deployment to effectively communicate across a firewall will depend on what
functionality you wish 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 has been done on a build LAN.
An example would be in a demilitarized zone (DMZ), where servers are to be
built and rebuilt. It is highly unlikely that DHCP, PXE, and multicast will 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 the tables above as a guide to help you decide which services are required
and therefore 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. They include:
򐂰 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. 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. Radius authentication is similar to
Active Directory 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 is similar
to the domain authentication; however, authentication and group membership
is with 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.
44
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
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. The LAN speed is 100 Mbps. The
workstations have been acquired over a five year period and there were, at last
count, 12 different hardware configurations, with no Standard Operating
Environment (SOE). The CIO has 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 1 GB switch to
the network backbone. Last year, one of the organization’s application server
disks failed. The backups were all current, but there was no build process for the
server. The technician who had built the server had left the company. Because
no one could find the build media for the OS or the application, it took three
frantic days to rebuild the server and bring it back online. 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
High speed network backbone
DB
Other servers
Workstations
Figure 2-7 Small site topology
Chapter 2. Architecture and deployment scenarios
45
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 the 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 the 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 design” on page 46 describes
how they set up their environment to exploit the tool to their best advantage.
The design
The requirements stated above can easily be fulfilled by a single Tivoli
Provisioning Manager for OS Deployment server located within the server farm in
the data room. This server would like the rest of the server fleet.
Server hardware
A separate server was decided upon, as the existing servers are currently all
fairly heavily utilized. The specification of this server is laid out in Table 2-3.
Table 2-3 Small site server specification
Quantity
Server type
Speed
RAM
Free Disk
1
Dual Xeon
1 Ghz
1 GB
10 Gb
This is the minimum specification for a Tivoli Provisioning Manager for OS
Deployment server, as documented in Tivoli Provisioning Manager for Operating
System Deployment Guide (Fix Pack 1), SC32-2582.
As there is going to be one PXE server and several subnets, it will be important
to setup DHCP with options 43 and 60 enabled and configured so that the
workstations will know the IP address of the PXE server.
Profiles
Due to the fact that the CIO wants to see a quick return on his investment with an
almost immediate reduction in the cost of rebuilding workstations, it is decided
that the following approach to build profiles will be taken.
46
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Unattended setup profiles
The current workstation fleet consists of a variety of hardware and only ad hoc
rebuilds are currently being executed. So the decision is made to quickly
implement an unattended setup of Windows 2000 and Windows XP that will
cater to the variety of hardware currently used by the organization. It takes the IT
department just one day to assemble all of the drivers necessary to build a
current Windows 2000 workstation and a Windows XP workstation. This
unattended setup is ready for use in one day.
The same process is used for the assembly of the server build.
Clone profile
The move to Microsoft Vista is a longer term project. The IT department are
developing a SOE that will have the same base for all users, plus certain
applications for specific job roles. They have studied the capabilities of Tivoli
Provisioning Manager for OS Deployment closely and have decided to deploy
these common applications as a part of the base image and other optional
applications where possible as part of the deployment.
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.
Deployment schemes
A number of deployment schemes are set up to meet the following conditions:
򐂰 The rollout of new computer hardware with the Vista SOE installed
򐂰 The rebuild of single computers
Chapter 2. Architecture and deployment scenarios
47
Multicast rollout deployment scheme
This scheme will be used for new hardware deployments where groups of
workstations will be built together. The characteristics of this deployment scheme
are detailed in Table 2-4.
Table 2-4 Multicast rollout deployment scheme
Settings
Setting
Comment
Allow BOM editing
Never (Always run
unattended)
Not necessary; all host
information to be preloaded.
Request User confirmation
No
No allowance is made for
the user to reject a 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
end
Yes
Another configuration will
be bound later.
Deployment status report
Store full log
General settings
Save deployment log to:
Hardware inventory
PCI, Disk, DMI
Perform Inventory
Locked
Store hardware but no
software.
Network settings
48
Before start wait
120 seconds
To synchronize other
multicast clients.
Bandwidth limitation
50 Mbps
Deployment will be across
a production network
(potentially during the day).
Deploy using unicast
No
Using multicast.
Crypt network traffic
No
Within a private network.
Use “BIOS fall back
MBR“to start PXE
No
Not necessary; the adapter
was tested in this computer
model.
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Settings
Setting
Comment
Alternate image server
-
This build comes from the
designated server and no
other.
Redeployment
Redeployment partition
-
User authentication
-
Authentication options
-
Software binding settings
Discard all other binding
rules
No
Bound software
-
Apply group and hardware
binding.
Single computer deployment scheme
This scheme is for general use in one-off deployments or system rebuilds. The
deployment will occur over a production 100 Mbps 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
Allow BOM editing
Only for unknown new host
Unnecessary for rebuilds,
but possibly necessary for
a new computer,
Request User confirmation
Yes
Allows 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
end
No
This configuration.
Deployment status report
Store full log
General settings
Save deployment log to:
Chapter 2. Architecture and deployment scenarios
49
Settings
Setting
Comment
Hardware inventory
PCI, Disk, DMI
Store hardware but no
software.
Perform Inventory
Locked
Network settings
Before start wait
-
Not using multicast.
Bandwidth limitation
50 Mbps
50% of the 100 Mbps
production bandwidth.
Deploy using unicast
Yes
Crypt network traffic
No
Within a private network.
Use “BIOS fall back
MBR“to start PXE
No
Not necessary; tested the
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
rules
No
Bound software
-
Apply group and hardware
binding.
Computer boot sequence
There will be a variety of computer boot sequences for the different computers in
the organization’s environment. These are detailed below, including the
reasoning behind each one.
50
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Servers
Once built, servers will have their boot sequence changed to:
1. Hard Disk
2. CD ROM
3. Removable device
4. Network Boot
To ensure that an inadvertent network boot does not start a deployment, the boot
setting for the server group is set to boot from hard drive. For a deployment to
occur, this must be explicitly overridden.
Workstations
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 to shut down and restart the computer off the network without
needing to ask the user to change the boot order when a workstation needs to be
rebuilt
Migration strategy
Due to the small size of the organization, new profile and deployment schemes
are 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.
Chapter 2. Architecture and deployment scenarios
51
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 (they are laid out in Table 2-6). The
roles range from Administrative access down to the sort of very restricted access
that would be given to contracted staff during a rollout.
Table 2-6 Security roles
Role
Active
Directory
Group
HTTP console
access
Security policy
Administrator
Administrators
Access all areas
No restriction
Developer
Developers
OS Deployment - Yes
Server Log files - Yes
Server parameters No
Server status - Yes
Deny changes to the server configuration
Operator
Operators
OS Deployment - Yes
Server Log files - No
Server parameters No
Server status - Yes
Deny addition/removal of hosts
Deny any changes to RAD hosts
Deny changes to the server configuration
Installer
Installers
OS Deployment - Yes
Server Log files - No
Server parameters No
Server status - No
Deny addition/removal of hosts
Deny any changes to RAD hosts
Deny changes to RAD deployment schemes
Deny changes to RAD software packages
Deny changes to RAD system profiles
Deny changes to the server configuration
2.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, that is, a
central database for the deployment history and inventory. A central database will
also provide 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
52
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
will allow for the capture and testing of profiles, deployment schemes, and the
export/import process between environments.
The high level requirements of the system are:
򐂰 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 above 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
53
Test facility
The test facility is installed as two separate systems, first, the development
environment, and then the pre production environment. Both of these
environments would be 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
One standalone server + workstations
–
On which new profiles, packages, … are created
–
One workstation of each type
–
Allows to test
• Tivoli Provisioning Manager for OS Deployment
objects creation
• Tivoli Provisioning Manager for OS Deployment
objects deployment
• Tivoli Provisioning Manager for OS Deployment
archive exportation
Same as production environment
–
To a lower scale
• 1 regional server only
–
Allows to test
• Server replication
• Tivoli Provisioning Manager for OS
Deployment archive importation
• Deployment of RAD objects
• Backup mechanism in case of slave failure
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
54
Quantity
Server type
Speed
RAM
Free disk
1
Dual Xeon
1 Ghz
1 GB
10 Gb
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
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 Redbook publication, we
ran a Tivoli Provisioning Manager for OS Deployment server on a variety of
hardware, including a single CPU 512 MB VMware workstation.
Development 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,
mobile computers, servers, and virtual systems.
Development installation
Installation of the Development Tivoli Provisioning Manager for OS Deployment
server is simple, as it uses the standard database, so it is just a matter of
following the installation wizard.
Pre-production environment
The pre-production environment is a representative subset of the production
environment. It consists of a master server, a slave server, and, where possible,
one of each production target systems.
Depending on the actual production topology, it may be prudent to incorporate a
simulated or real slow network link between the master and slave servers.
For the purposes of this exercise, we have drawn the pre-production environment
with no reference to other systems; in reality, the pre-production environment
may be built within an existing pre-production environment representing a branch
or department of an organization. This can be an important factor, as the
systems will be co-existing in the production environment and sharing resources,
such as server hardware and network bandwidth. It is important to understand
how the replication of images between servers will affect ongoing transactions
and backups and so on.
Pre-production server hardware
Table 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
1 Ghz
1 GB
10 Gb
Chapter 2. Architecture and deployment scenarios
55
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,
mobile computers, servers, and virtual systems.
Pre-production installation
The pre-production environment’s installation is a little different than the
development environment in that it utilizes a multi-user relational database
management system. 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. Once both 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 production environment, this replication regime should be the same
as in the production environment. A discussion regarding the different replication
methods is included in “Image replication” on page 31.
Production environment
The production environment shown in Figure 2-9 on page 57 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.
56
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
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 server
Figure 2-9 Production environment
The server specifications are shown in Table 2-9.
Table 2-9 Server specifications
Servers
Applications
run
Server
type
Speed
RAM
Free disk
London Master
Tivoli
Provisioning
Manager for
OS
Deployment
DB2®
Dual
Xeon
1 GHZ
2 GB
100 GB
Branch
Servers - slave
File and Print
services
Dual
Xeon
1 GHZ
1.5 GB
60 GB
dedicated
disk
The master server is running 1 GB of RAM for the Tivoli Provisioning Manager for
OS Deployment server and 1 GB for the DB2 server. As this will be a small
database by any standard, and there will be minimal querying, it is not necessary
Chapter 2. Architecture and deployment scenarios
57
to increase the number of CPUs or separate the DB2 off onto a separate server.
100 GB of disk gives plenty of space for a large portfolio of images.
The branch file and print servers were all running 512 KB of RAM; this was
upgraded to 1.5 GB when the Tivoli Provisioning Manager for OS Deployment
was deployed along with a 60 GB 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 also currently 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 to not 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 on the back office
workstation, but with fewer control over 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
hardware
򐂰 Windows 2003 servers: The e-mail system, accounting application, and a
number of back-end IT systems, such as the backup, run on a Windows 2003
platform. This platform is run 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.
58
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
򐂰 A Windows Vista™ SOE is in development for the various workstation
categories above.
Unattended setup profiles
We 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. This
is because the predominant reason that one of the existing servers would be
rebuilt would be as part of a disaster recovery plan (the disaster could be a
machine or site failure). If that were to happen, the chances that the hardware the
organization would be able to use for the replacement server would not
necessarily be the same or even come from the same vendor as the original
server. Therefore, we thought that the unattended setup offered more flexibility in
this instance.
Clone profile
A universal image is developed for all SOE versions. Across the 400 workstation
computers, there are only 15 different models, so it is easy to build the necessary
driver packages for injection into the image during the build process. The image
is based upon the transaction workstation used by operators for face to face and
phone based transactions.
A naming convention within the organization designates a workstation’s function,
and also the group that it is assigned to within Tivoli Provisioning Manager for OS
Deployment. Each group has a profile bound to it so that when the workstation is
built or rebuilt, it automatically gets the correct profile.
The driver packages are bound to the PCI ID of the component it supports and
are automatically installed with an image if the computer hardware requires the
driver.
The base software required by all users has been included in the universal
profile.
Deployment schemes
A number of deployment schemes are to be set up to meet the following
conditions: the bulk rollout of new computer hardware with the Vista SOE
installed, the rebuild of a single computer, the build of a single computer, and the
build of a redeployable computer. This equates to three deployment schemes.
Details of those three schemes follow.
Chapter 2. Architecture and deployment scenarios
59
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 shown in Table 2-10.
Table 2-10 Multicast rollout deployment scheme
Settings
Setting
Comment
Allow BOM editing
Never (Always run
unattended)
Not necessary; all host
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
end
Yes
Another configuration will
be bound later.
Deployment status report
Store full log
General settings
Save deployment log to:
Hardware inventory
PCI, Disk, DMI
Perform Inventory
Locked
Store hardware but no
software.
Network settings
60
Before start wait
120 seconds
To synchronize other
multicast clients.
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“to start PXE
No
Not necessary, tested the
adapter in this computer
model.
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Settings
Setting
Comment
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
rules
No
Bound software
-
Apply group and hardware
binding.
Single computer deployment scheme
This scheme is for general use in one-off deployments or system rebuilds. The
deployment will occur over a production 100 Mbps LAN probably during business
hours. The characteristics of this scheme are shown in Table 2-11.
Table 2-11 Single computer deployment scheme
Settings
Setting
Comment
Allow BOM editing
Only for unknown new host
Unnecessary for rebuilds,
but possibly necessary for
a new computer.
Request User confirmation
Yes
Allows 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
end
No
This configuration.
Deployment status report
Store full log
General settings
Save deployment log to:
Chapter 2. Architecture and deployment scenarios
61
Settings
Setting
Comment
Hardware inventory
PCI, Disk, DMI
Store hardware but no
software.
Perform Inventory
Locked
Network settings
Before start wait
-
Not using multicast.
Bandwidth limitation
50 Mbps
50% of the 100 Mbps
production bandwidth.
Deploy using unicast
Yes
Crypt network traffic
No
Within a private network.
Use “BIOS fall back
MBR“to start PXE
No
Not necessary; tested the
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
rules
No
Bound software
-
Apply group and hardware
binding.
Redeployment deployment scheme
Due to the utilitarian nature of the transaction workstations, these workstations
will be deployed with a redeployment scheme. The workstations will have a
customized menu with two options:
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 will be returned to its
pristine state, reducing the need to log calls to the help desk for computer
configuration issues.
62
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
A screen capture of the menu is provided in Figure 2-10.
Figure 2-10 Customized redeployment menu
The deployment scheme settings are shown in Table 2-12.
Table 2-12 Redeployment deployment scheme
Settings
Setting
Comment
Allow BOM editing
Only for unknown new host
Unnecessary for rebuilds,
but possibly necessary for
a new computer.
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.
General settings
Chapter 2. Architecture and deployment scenarios
63
Settings
Setting
Comment
Unbind configuration at the
end
No
This configuration and
deployment scheme are to
be bound to this computer.
Deployment status report
Store full log
Save deployment log to:
Hardware inventory
PCI, Disk, DMI
Perform Inventory
Locked
Store hardware but not
software.
Network settings
Before start wait
-
Not using multicast.
Bandwidth limitation
50Mbps
50% of the 100 Mbps
production bandwidth.
Deploy using unicast
Yes
Crypt network traffic
No
Within a private network.
Use “BIOS fall back
MBR“to start PXE
No
Not necessary; tested the
adapter in this computer
model.
Alternate image server
-
There is no other local
build server.
Redeployment partition
2000 Mb
The size of the SOE.
User authentication
Does not require
authentication
Authentication options
-
Redeployment
Software binding settings
64
Discard all other binding
rules
No
Bound software
-
Apply group and hardware
binding.
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Computer boot sequence
There will be a variety of computer boot sequences for the different computers in
the organization’s environment. These are detailed below, including the
reasoning behind each one.
Servers
Once built, servers will have their boot sequence changed to:
1. Hard Disk
2. CD ROM
3. Removable device
4. Network Boot
To ensure that an inadvertent network boot does not start a deployment, the boot
setting for the server group is set to boot from hard drive. For a deployment to
occur, this must be explicitly overridden.
Transaction workstations
The transaction workstations that will have a redeployment image stored locally
will be permanently set to boot in the following order:
1. Network
2. CD ROM
3. Removable device
4. Hard disk
Booting off the network or the hard drive looks the same on a redeployable
computer. There are two extra windows: the Tivoli splash window and the
redeployment menu. However, when booted off the network, those windows are
sourced from the Tivoli Provisioning Manager for OS Deployment server and
therefore can be changed by the administrator, adding or removing items without
it being necessary to visit each computer. It is also possible to send a new image
to the computer without any physical contact to it.
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
Chapter 2. Architecture and deployment scenarios
65
These workstations will also have the RbAgent loaded. This will allow an
administrator, in a situation where a workstation needs to be rebuilt, to shut down
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. Once
a profile is ready for production migration, it will be migrated from test to
pre-production through a DVD. This process is explained in detail in “Migration
strategy” on page 51.
Once the profile has been 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 will ensure 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 use within the organization. We decide to
use the current tool for a number of reasons:
1. Replication really only need to be done on an ad hoc basis, and therefore
having another scheduled task in the network is 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
has 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.
We decide that this will also be used for authentication in the Tivoli Provisioning
Manager for OS Deployment solution.
Four user groups are created within Active Directory, one for each Tivoli
Provisioning Manager for OS Deployment role. In the HTTP Console Security
window, 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 shown in Table 2-13.
66
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Table 2-13 Security roles
Role
Active
Directory
group
HTTP console
access
Security policy
Administrator
Administrators
Access all areas.
No restriction.
Developer
Developers
OS Deployment - yes.
Server Log files - yes.
Server parameters No.
Server status - Yes.
Deny changes to the server configuration.
Operator
Operators
OS Deployment - yes.
Server Log files - No.
Server parameters No.
Server status - Yes.
Deny addition/removal of hosts.
Deny any changes to RAD hosts.
Deny changes to the server configuration.
Installer
Installers
OS Deployment - yes.
Server Log files - No.
Server parameters No.
Server status - No.
Deny addition/removal of hosts.
Deny any changes to RAD hosts.
Deny changes to RAD deployment schemes.
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. We decide 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 China. The head
office is still based in London. The existing architecture needs to be changed to
more effectively deal with the larger organization.
Chapter 2. Architecture and deployment scenarios
67
Architecture
The new architecture will incorporate three tiers and break the organization up
into three regions, which are;
򐂰 Great Britain
򐂰 Europe
򐂰 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
2
London
•
•
Level 1 server has an independent database.
– Specific replication mechanism between level
1 and 2 servers
Level 2 and 3 servers share databases
Level 2 are backup for level 3 servers.
Great-Britain
Europe
Asia
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.
68
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
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 one, being able to stop and start
replication, dynamically adjust bandwidth utilization to the level of traffic in the
network, and schedule data movement adds real value.
The process to drive replication from the command line is described in “Image
replication” on page 31.
Test environment
Just as the architecture of the production environment has changed with the
expansion of the organization, the test facility must change as well. There is little
point to having a pre-production environment if it does not mirror production in at
least the major functions. In the case of the test facility, to mirror production we
need to add another level of the server to replicate the master site. The server
that was the master server will now replicate that of a regional center. The new
master server will have its own database that will not contain any host
information; this information is kept down at the regional level. This architecture is
shown in Figure 2-12
Adapting the test facility
•
Development server remains identical
•
Pre-production server adds one level of servers
RAD archive
transfer
Figure 2-12 Expanding the test facility
Chapter 2. Architecture and deployment scenarios
69
70
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this IBM Redpaper.
IBM Redbooks publications
For information about ordering these publications, see “How to get IBM
Redbooks publications” on page 71. Note that some of the documents
referenced here may be available in softcopy only.
򐂰 Deployment Guide Series: Tivoli Provisioning Manager for OS Deployment
V5.1, SG24-7397
Other publications
These publications are also relevant as further information sources:
򐂰 Tivoli Provisioning Manager for Operating System Deployment Guide (Fix
Pack 1), SC32-2582
Online resources
These Web sites are also relevant as further information sources:
򐂰 IBM OPAL Web site
http://www.ibm.com/software/tivoli/features/it-serv-mgmt/opal.html
How to get IBM Redbooks publications
You can search for, view, or download Redbooks, IBM Redpapers, Technotes,
draft publications and Additional materials, as well as order hardcopy Redbooks,
at this Web site:
ibm.com/redbooks
© Copyright IBM Corp. 2007. All rights reserved.
71
Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
72
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Index
Symbols
.NET Framework 3.0 6
A
Access database 39
Active Directory 44, 52
advanced hybrid images 11
assessment of a deployment tool 10
AutoDeploy 56
B
bandwidth controlled replication 20
binding 26
BitLocker 7
blind migration 9
boot from CD/DVD 20
boot options
hard drive boot 36
network boot 37
business requirements 6
C
client boot options 36
cloned image 22–23
cloning process 23
Command line export utilities 20
common OS deployment scenarios 13
rebuild of a previously deployed user workstation
14
rollout of new desktop hardware 14
upgrade of hardware and subsequent Vista install 15
Configuration Life cycle 3
network usage 28
soft synchronization multicast 30
unicast 28
network usages
synchronized multicast 30
DHCP discovery packets 42
DHCP server 42
disk types 24
DMZ (demilitarized zone) 44
driver injection 18
driver package 22, 24
driver package creation wizard 25
Dynamic Host Configuration Protocol (DHCP) 41
E
efficiency in storage 24
efficient image storage 19
F
firewalls 42
fresh OS install 9
G
greater security 6
H
host names 26
assigned by Tivoli Provisioning Manager for OS
Deployment 26
automatic generation 26
importing 26
manually entering 26
I
D
Deploy Now function 37
deployment rule 24
deployment scheme 19
actions 27
data collection 27
multicast rollout 48
© Copyright IBM Corp. 2007. All rights reserved.
IBM Director 3
IBM OPAL website 34
image replication 31
built in file replication service 32
how it works 31
73
L
S
locked window 37
SAN (storage area network) 39
save money 6
scheduled replication 20
security 44
Security Development Life cycle (SDL) 6
server specification 39
slave servers 56
SMB (Server Message Block) 13
snapshot 23
soft synchronization multicast 30
software deployment 18
software package 22, 25
Standard Operating Environment (SOE) 7, 45
subnets 45
switched network 39
Sync.PAK file 34
synchronized multicast 30
sysprep 22
M
Mac OS-X 12
Microsoft Vista 6
Microsoft Vista support 18
Microsoft WIM images 12
Microsoft WinPE 12
mini setup 23
MSI (Microsoft Installer Package) 25
multicast 11
multicast packets 30
multiple subnets 17
N
network bandwidth savings 19
network bandwidth utilization 19
network boot 26
network booting without PXE 40
Network sensitive image replication 20
no touch build capability 18
O
older versions of Windows 6
option 43 42
option 60 42
P
PKGADD 25
Preboot eXecution Environment (PXE) 40
profile 18
exporting 35
importing 35
migration 34
R
RAD Export Wizard 35
RbAgent 15, 33–34, 37, 40, 51, 66
RDBMS vendor 39
Redbooks Web site 71
Contact us viii
redeployment 20, 37
how it works 38
repository synchronization 34
RPM (Red Hat Package Management) 25
74
T
ThinkVantage Access Connection 9
Tivoli Provisioning Manager for OS Deployment 3,
45
architecture 21
binding 26
capabilities 5
client boot options 36
common OS deployment scenarios 13
Configuration Life cycle 3
deployment scenarios
enterprise 52
company expands 67
deployment schemes 59
design 53
small site 45
deployment scheme 49
design 46
topology 45
deployment scheme 27
driver packages 24
DVD deployment 41
features 18
adjustable network bandwidth utilization 19
boot from CD/DVD 20
build from DVD 19
design considerations 21
driver injection 18
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
highly efficient image storage 19
network sensitive image replication 20
no touch build capability 18
redeployment 20
software deployment 18
system cloning 18
uattended setup 19
unicast and multicast image deployment 19
universal system profile 18
image replication 31
kernel 40
redeployment 37
security 44
Software packages 25
unattended setup 21
universal system profile 24
Trustworthy Computing Initiative 7
U
unattended setup 19
advantage 21
universal system profile 24
user data migration strategy 9
V
Vista 7, 47
Vista migration 9
Vista support 18
Vista's Aero Glass interface 6
W
WIM (Windows Imaging) 12
Windows 2000 45
Windows Communication Foundation (WCF) 6
Windows INI file 25
Windows registry 25
Windows Vista SOE 59
Windows Workflow Foundation (WWF) 6
Windows XP 45
Index
75
76
Architecting a Highly Efficient Image Management System with Tivoli Provisioning Manager for OS Deployment
Back cover
Architecting a Highly Efficient
Image Management System
with Tivoli Provisioning
Manager for OS Deployment
Guidelines for
selecting an image
management
solution
Architectural
considerations for
the TPM for OS
deployment solution
Deployment
scenarios and case
studies
Tivoli Provisioning Manager for OS Deployment provisions
operating systems and applications to computers using the
Pre-boot eXecution Environment (PXE) 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,
SMB, or larger accounts.
In this IBM Redpaper, we discuss how to design and
implement a highly effective image management solution for
small, medium, and enterprise accounts, taking network
bandwidth limitations and large OS image sizes into
consideration. We also cover the considerations for choosing
an image management solution and the benefits of
implementing such an environment.
Note that this IBM Redpaper is more geared to IT Architects.
For a full discussion of Tivoli Provisioning Manager for OS
Deployment, including installation, customization, and other
product integrations, refer to Deployment Guide Series: Tivoli
Provisioning Manager for OS Deployment V5.1, SG24-7397.
®
Redpaper
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks
REDP-4294-00