Columbus OSDeploy

Columbus OSDeploy
Version 6.7
Brainware Consulting & Development
Copyright © 1997-2005 Brainware Consulting & Development AG
All rights reserved
The software contains proprietary information of Brainware Consulting & Development AG; it is provided
under a license agreement containing restrictions on use and disclosure and is also protected by copyright law.
Reverse engineering of the software is prohibited.
Due to continued product development this information may change without notice. The information and
intellectual property contained herein is confidential between Brainware Consulting & Development AG and
the client and remains the exclusive property of Brainware Consulting & Development AG. If you find any
problems in the documentation, please report them to us by sending a mail to Helpdesk@brainware.ch.
Brainware Consulting & Development AG does not warrant that this document is error-free.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any
means, electronic, mechanical, photocopying, recording or otherwise without the prior written permission of
Brainware Consulting & Development AG.
Microsoft Word, Microsoft Office, Windows®, Windows NT®, Windows XP™, Windows 2000™, Windows 2003™
and MS-DOS™ are trademarks of the Microsoft Corporation.
All other products mentioned are registered trademarks or trademarks of their respective companies.
Brainware Consulting & Development AG
Sumpfstr. 15
CH-6300 Zug
+41 41 748 22 00
helpdesk@brainware.ch
www.brainware.ch
Table of Contents
Welcome to Columbus <Product_MajorVersion.......................................................................... 3
About this manual...................................................................................................................................................................................... 3
Typographical conventions ....................................................................................................................................................... 3
Do you want to send us information? ................................................................................................................................... 4
Columbus OS Deploy ................................................................................................................................................................................. 5
Terms used ..................................................................................................................................................................................... 6
Setting up OS deployment ............................................................................................................... 9
Installation options .................................................................................................................................................................................... 9
Adding additional operating systems ................................................................................................................................................10
Columbus System Settings......................................................................................................................................................11
OS Deployment dialog ..............................................................................................................................................................12
Updating a OSDepot................................................................................................................................................................................13
Tailoring the OS Deploy configuration ..............................................................................................................................................14
Refreshing the database.........................................................................................................................................................................15
Setting up computers...................................................................................................................... 19
Setup with Columbus Console and PXE ............................................................................................................................................19
Integrating computers by means of PXE.............................................................................................................................20
Selecting the Computer............................................................................................................................................................23
Staging one computer per console .......................................................................................................................................24
Starting the installation ...........................................................................................................................................................32
Setup with boot diskettes ......................................................................................................................................................................34
Creating a boot diskette...........................................................................................................................................................34
Staging a computer by means of a boot diskette ............................................................................................................43
Floppy Maker................................................................................................................................................................................59
Getting to grips with OS deployment .......................................................................................... 63
Configuration.............................................................................................................................................................................................65
Structure........................................................................................................................................................................................66
Releases .........................................................................................................................................................................................67
Sites & configs.............................................................................................................................................................................68
OS Deploy jobs.............................................................................................................................................................................76
Configuring Floppy Maker .......................................................................................................................................................86
Migration of AutoSetup environmments .........................................................................................................................................99
Important differences...............................................................................................................................................................99
How to migrate? ...................................................................................................................................................................... 101
Configuring infrastructure services ................................................................................................................................................. 102
The infrastructure services can be configured as follows .......................................................................................... 102
OS deployment......................................................................................................................................................................... 103
Preboot services ....................................................................................................................................................................... 107
Pre-Boot Execution Environment (PXE) .......................................................................................................................................... 107
WakeOnLan ............................................................................................................................................................................... 108
PXE images ................................................................................................................................................................................ 108
PXE and OS Deploy .................................................................................................................................................................. 109
Columbus PXE filtering.......................................................................................................................................................... 111
Troubleshooting OS deployment...................................................................................................................................................... 113
BIOS update............................................................................................................................................................................... 114
Check the policy entries in Windows 2003 servers ...................................................................................................... 114
i
LMHOSTS file............................................................................................................................................................................. 116
Native NDIS driver and PXE .................................................................................................................................................. 117
Finding network components causing errors................................................................................................................. 118
Hard disk images.................................................................................................................................................................................... 118
Preparing a disk image for OS deployment..................................................................................................................... 119
The Image directory ................................................................................................................................................................ 120
Security...................................................................................................................................................................................................... 123
Release security........................................................................................................................................................................ 123
Directory security..................................................................................................................................................................... 123
Columbus account .................................................................................................................................................................. 124
Index.................................................................................................................................................125
ii
Contents
Welcome to Columbus
<Product_MajorVersion
We are pleased that you have chosen Brainware and Columbus 6.
Columbus 6 provides you with a powerful software and client management system. In
developing this system, we have tried to take note of the requirements and wishes of our
customers and partners.
About this manual
In this manual we want to provide you with a detailed view into the OS Deployment
module of Columbus 6. This manual concentrates on the specifics of OS deployment and
requires a knowledge of the basics of Columbus.
The manual Columbus First Steps guides you through the first time installation of a
Columbus system..
The manual Columbus Basics provides information about the basic functions and operation
of the Columbus Management Console as well as the configuration of the infrastructure
and setting up of authorizations.
How to migrate from previous AutoSetup version is explained in chapter Migration von
AutoSetup (See "Migration of AutoSetup environmments" on page 99)
Typographical conventions
Before reading through this manual it is important that you have understood the concepts
used therein and the typographical conventions.
Detailed information about the concepts used can be found in the glossary at the end of the
document.
The following formatting is used for special information.
Formatting
Triangular symbol '
Type of information
' Step-by-step procedure. Follow these steps to
complete a task.
Bold special
Selection points, such as menu options, buttons or
elements in a list.
Cursive
Stresses the importance of a point.
Also used for variables and parameters.
3
CAPITAL LETTERS
Names of keys on the keyboard. Examples: SHIFT,
CTRL or ALT.
KEY+KEY
Key combinations where the user must hold a key
down and press another key. Examples: CTRL+P or
ALT+F4.
Do you want to send us information?
We are constantly striving to optimize Columbus 6 and are therefore looking for new and
improved options for documentation and use of our products. If you have any suggestions,
criticisms or praise, please contact us.
You can reach us as follows
Brainware Consulting & Development AG
Brainware Solutions AG
4
Address
Sumpfstr. 15, CH-6300 Zug, Switzerland
Web
www.brainware.ch
e-mail
helpdesk@brainware.ch
Telephone:
+41 41 748 22 00
Fax:
+41 41 748 22 01
Columbus OSDeploy
Columbus OS Deploy
Columbus OS Deploy ensures automated operating system installation and complete
configuration and integration of client and server systems. This includes:
Operating system installation
Hardware configuration (drivers, settings and security)
Desktop and personal settings
Network configuration (name, TCP/IP, domain affiliation)
Other items such as registry settings, files, connection to a software distribution, etc.
Columbus OS Deploy is based on Microsoft Unattended Installation Technology, and
extends the technology by means of so-called 'jobs'. These ultimately allow for the
automation of individual configuration and integration of installed clients and/or servers.
In addition, Columbus OS Deploy supports cloning procedures based on Paragon's Disk
imaging tools. Symantec Ghost™ (up to Version 7.5) is also supported out of the box and
further tools can be integrated upon request. OS Deploy is capable of using existing images
for quick basic installation. After an image has been successfully applied, OS Deploy takes
over the individual and time-consuming configuration and integration steps automatically
by means of predefined 'jobs'. Columbus OS But Deploy goes even further. It is possible to
generate a Ghost Image during a normal, unattended installation, and to use this image for
further, image based rollouts.
OS Deploy supports the following boot media and technologies:
PXE Preboot Execution Environment (including Preboot Inventory)
Network boot (F12)
Boot floppy
Bootable CD-ROM and DVD
Local hard drive
Removable drives (ZIP & JAZZ drive)
Differences between OS Deploy Standard and OS Deploy Enterprise
The following performance features are only available in the Enterprise Edition:
Installation of server operating systems
Support for disk images (e.g. Symantec Ghost™)
Welcome to Columbus <Product_MajorVersion
5
Terms used
We would like to familiarize you with the base components of OS Deploy, by means of the
following explanations. Please read this section carefully to familiarize yourself with
terminology used. The following sections build on the terms used here.
Here you can find out what
terminology is used.
The components of the OS Deploy system
The functionality of these components
Here we refer to the base elements of OS Deploy that are used in a local area network (LAN),
and the most frequently used environments for OS Deploy. Later we will also discuss OS
Deploy in other environments (remote access, WAN, MAN)
Staging
This refers to the complete installation of a computer, i.e. the user can operate the
computer at the end of the installation process It includes the boot process, partitioning of
the hard drive(s), the installation of the operating system and the configuration of the
system according to company standards.
Windows
In this manual the term Windows refers to all versions of Microsoft Windows that are
based on NT technology (Microsoft® Windows® NT, Windows® 2000 and Windows® XP).
Windows® 9x and ME are not supported by OS Deploy.
Unattended Windows Setup
The so-called Unattended Setup is a process whereby Windows systems can be installed
without manual intervention. This is provided for Original Equipment Manufacturers
(OEMs), system administrators, Value Added Resellers (VARs) and others.
Distribution point
Distribution point describes the location at which the source for the Windows installation is
provided. The computer links to the distribution point to execute the setup during
installation. Typically, this is a directory on a server that can be addressed via a release.
Alternatively, you can use a CD-ROM, a Jaz Drive, an additional hard drive, extended
partitions or similar.
OS Deploy release
OS Deploy release is made available at a distribution point and makes a version of an
operating system available. This can be Windows 4.0, Windows 2000 (Workstation or
Server), Windows XP or Windows 2003 Server. OS Deploy release includes certain languages
such as Japanese, Chinese and Korean. In addition to the operating system, it includes
various OS Deploy jobs that contain the drivers necessary for your hardware, and
configuration settings for your environment. A release not only installs a certain operating
system, but also configures your computers entirely according to your standards. As such, a
release is the foundation of a stable IT infrastructure.
6
Columbus OSDeploy
OS Deploy job
A job is a module for a release that performs a certain function for OS Deploy. That can be a
modification of the unattend.txt file, a driver installation or the configuration of a setting.
Owing to its modular composition, OS Deploy is very flexible and easy to maintain and
update.
PXE
By now, the Pre-Boot Execution Environment replaces the boot diskette, for connecting to
the distribution point. All actions possible by means of the boot diskette can also be
performed by PXE, with the advantage that it is no longer necessary for someone to locally
boot the computer from a diskette.
WoL
Wake on Lan enables you to remotely power up a computer via a connected network.
Boot disk
A boot diskette can be used to link to the distribution point when performing a Windows
installation. Normally partitioning of the local hard drive is performed prior to the
installation of Windows; a boot diskette can also be used for this. If your computer has
setup partitions or boot managers, even small errors can lead to a complete loss of the hard
drive contents. Our partition manager can automatically format your hard drives as desired,
without the risk of losing data.
OS Deploy is supplied with a modular boot diskette that is equipped with many options for
connecting to the distribution point. Additional modules for the boot diskette are available
on our web site, or can be added personally. The actual Windows setup runs under DOS and
requires a FAT16 partition.
When using a boot diskette, it is possible to change the function of the diskette used to that
of a rescue disk; only one keyboard entry is then required to reinstall the computer - in some
cases no keyboard entry is required.
Floppy Maker
Floppy Maker is a tool for managing boot diskettes. Diskettes can be created and changed,
and reusable images can be stored.
Profiler workstation
Profiler is a Windows application that enables you to determine all the information needed
for the installation of a computer by using a user-friendly front end. All entries can be
predetermined so that options can be limited. Passwords used are stored in an encrypted
form so that maximum security can be ensured.
Hardware models and network environments are stored as templates so that easily
understood default values for machine configurations and locations can be made available.
Welcome to Columbus <Product_MajorVersion
7
Mandatory and optional jobs can be integrated by means of additional job lists. In this way
it is also possible to integrate 'exotic' hardware that is not recognized by Windows Setup. It
is also possible to include a version of MS Office on the computer. This mechanism is
supported by a script language that is easy to learn. It is possible to integrate other familiar
script languages such as Perl, VB, etc.
OS Deploy account
If the distribution point is in a network release, it is necessary to enter a user ID that is
authorized to connect to this release. We recommend giving this account the authority to
add machines to the domain.
Columbus Management Console
The preferred tool for the installation of computers and central distribution of software
from Columbus 6.
Connector
Floppy Maker uses connectors to connect to the respective installation source (network, CDROM etc.) They contain the necessary drivers.
8
Columbus OSDeploy
CHAPTER 1
Setting up OS deployment
The installation of Columbus is described in detail in the manual First Steps. Here, we only
deal with the details of an OS deployment installation. This includes subsequent adding of
additional operating systems, for example.
In this chapter
Installation options.............................................................................. 9
Adding additional operating systems ........................................... 10
Updating a OSDepot............................................................................ 13
Tailoring the OS Deploy configuration.......................................... 14
Refreshing the database .................................................................... 15
Installation options
As a minimum, you need the following components for a functioning OS deployment
Management Console
Columbus database server
Columbus infrastructure server
contains the Columbus Preboot environment (PXE)
OS Deployment Depot with at least one operating system release
Select the following options in the setup dialog for a complete installation of OS
deployment on a server
9
Adding additional operating systems
You can add extra frameworks for additional operating systems to your OS Depot at any
time. To do this, start the setup again and make sure that the path to the data directory and
the Columbus release correspond to the previous installation. Setup should be able to take
over this information correctly from the report of the last installation.
All you need to do is select the Option OS deployment and the required operating system in
the Options dialog
Because a different system account can be used for every operating system release, the
dialog for entering the Columbus system account appears.
Important: The password is not taken over from the original installation. Enter the correct
password.
The OS Deployment dialog then appears. Here you need to enter the path to the Windows
source, the volume license key and the password for the local administrator on new
computers, for every release selected.
Setup then copies the required files. If you entered the i386 directory, this can take some
time.
10
Columbus OSDeploy
Columbus System Settings
The highest level structural element in a Columbus structure is the company. Enter the
name of the company you want to manage with Columbus. The Setup Wizard ill create this
company in the tree structure. You may change the name in the console at any time.
Various Columbus components need specific access permissions for instance to access the
OS sources, software packages, for adding newc omputers to the Active Directory or for
installing Software. Setup will create an own user account for this.
If an user account with appropriate rights already exists, you may enter this one. Of course
you may change the account later.
Confirm your choice with Next>.
Hint: According to your privilegies or depending from which server you have started the
setup, the user cann't get created automatically. So in case of an error message, you have to
create the account manually. It is recommended to check this account in the Active
Directory anyway and to make sure that the account has the needed permissions.
This user account has the following characteristics:
Write access to the data directory entered by you on the Columbus server
For certain OS deployment functions such as disk imaging the account has write access
to certain directories in OS Depot.
Can add computers to the domain
is automatically added to the local administrator group on all computers where
Columbus is installed, so that the Columbus client has the rights necessary for software
installation.
Generally, a domain account is used for this purpose. For security reasons, the Columbus
account should under no circumstances have domain administrator rights.
Chapter 1 Setting up OS deployment
11
OS Deployment dialog
If you selected the components OS Deployment and a subordinate operating system
structure, you are asked at this point to enter the necessary values for the operating
systems selected.
Abbildung 1: Betriebsystem Optionen
Confirm your selection with Next >>.
A new page is started for each release selected.
If you have a special Windows 2000 volume license version, you do not need to enter a
Windows license number.
If you do not have the Windows source, i.e. the i386 directory from your Windows CD-ROM
handy, you can copy it into the corresponding release directory in the OS subdirectory at a
later stage.
Setup creates an i386 directory with a modified OOBINFO.IN_ (and OOBINFO.INI) file for
Windows XP and 2003 Server. Do not overwrite this file if you are copying the Windows files
manually, otherwise you will not be able to set up a computer with a fully automatic OS
Deploy.
12
Columbus OSDeploy
Updating a OSDepot
Updating existing OS Sources is only very limited possible as Setup can not detect manual
changes you have applied after the original installation. Therefore make sure to backup the
system before adding new components.
Setup can only update the standard Release-folders WinXP, Win2000, Win2000.Srv and
Win2003.Srv.
If you have done extensive adaptations to a release, the most secure way to protected the
modifications against unintentional updates, is to rename the release folder. With an
update you install the original release again and afterwards you update your own release
manually.
On a typical update mostly the following files/folders get replaced. With a migration on
Columbus 6. <Product_MinorVersion> all components listed below must be updated.
OSDepot
All batch files and tools must be replaced with the new versions
Computer.img
Support for new imaging tools may be added and batch files and
input scripts (Imageload.txt) may get upgedated.
FpyMaker
In Floppy Maker the master bootdisk image often gets updated and
new netcard drivers will be added. If you customize the parameter
file Params.txt, it is recommended to create a seperate folder for
this so an update cann't overwrite your settings.
Job
In the job folder mainly the ASetup, ASetup.img and Col6 job will get
updated regularely by Brainware.
We recommend to not customize these jobs directly. Create
seperate jobs with for example additional scripts. You will be able to
continue to use this jobs after updates without modifications.
All other jobs are optional and often just samples, which you may
customize.
ASetup
The ASetup job must always be replaced completely with the new
version. Don't mix different versions!
ASetup.img
This job also should get replaced by new versions.
Col6
In this job the Columbus Client files will get updated regularely.
Watch out, that an eventually customized Columbus.cfg survives an
update.
Configuration files
You will find the standard OSDeploy configuration files in the folder
[Release]\Site\MySite\Config\Generic.
Chapter 1 Setting up OS deployment
13
You should customize these files according to your needs. Create a new site or at least
rename the default config Generic, when you make modifications. An update will create a
config Generic again. You may compare your configuration files with the new ones and copy
eventually added entries into your existing files.
Tailoring the OS Deploy configuration
Setup is only partially suitable for subsequent modifications to the configuration such as
passwords, accounts, domains etc. The setup is designed for establishing a basic,
functioning default environment. It still needs to be tailored to your requirements, however.
Because OS Deploy operates not only via a database but also purely on a file basis, you will
find all configuration parameters in separate configuration files, which are best tailored
using a text editor. Precise information in this area can be found in the chapter Sites &
Configs (on page 68).
OS Deploy allows you to tailor the Windows setup parameter and to configure the
computer exactly according to your requirements. The OS Deploy jobs are available to you
as powerful tools for this purpose. More information can be found in the chapter OS Deploy
Jobs (on page 76).
Important: Every time the configuration files are modified and jobs are added, the
corresponding OS deployment must be selected in the console in the Infrastructure view
and a Schedule list refresh must be executed. In this way, the modifications are also taken
over into the database.
14
Columbus OSDeploy
Refreshing the database
If you make changes to the releases, sites, configs or jobs, the database must be refreshed
so that the changes are also reflected in the console.
Select the Infrastructure tab in the console, and then the OS Deployment service from the
list.
Abbildung 2: CMC Reiter Infrastructure
Now select 'Schedule list refresh' on the right hand side."
Abbildung 3: CMC Tab Infrastructure Refresh OS Depot
Click on 'Next >' to begin the configuration.
Chapter 1 Setting up OS deployment
15
Abbildung 4: CMC List refresh für OSDeploy konfigurieren
You can now enter the time at which the refresh should occur. If you do not make any
changes and you remove the check from 'Job is executed...', the refresh is performed
immediately.
To have a refresh performed periodically (e.g. every 24 hours), check the box and enter the
interval at which a refresh should occur. If you enter a time of '00:15:00' and an interval of
60 for example, a refresh will be performed every 60 minutes from 00:15 on the day
specified (00:15, 01:15, ...)
Once you have configured your settings, click on 'Next >' to continue.
Abbildung 5: CMC Aktualisierung konfiguriert.
Finally, the settings that you have configured are displayed once more. You can complete
the dialog using 'Finish'.
16
Columbus OSDeploy
Checking the refresh
Please select the Scheduled Actions tab from the field below to check a refresh configuration.
Abbildung 6: CMC Infrastructure Aktualisierung überprüfen
Name: Displays the name of the computer on which OS Deploy is installed.
Action: Shows which action will be performed. Here an 'OS refresh' is indicated - this
means a refresh of an OS Depot.
Timer: When the named action is to be performed.
Repeat: At what interval the action is to be performed.
Scheduled by: Who scheduled the action.
Scheduled at: When the action was scheduled.
ActionID: The ID of the action in the database.
Chapter 1 Setting up OS deployment
17
CHAPTER 2
Setting up computers
The easiest way to set up computers is to use the PXE functionality of Columbus. In this
way, the administrator is able to perform the operating system configuration via the
Columbus Management Console (CMC) and trigger its installation without someone
physically being at the computer.
If PXE is not used or if the network card is not PXE compatible, OS Deploy will be performed
by means of diskettes. The diskettes are created by means of the FloppyMaker and must be
used locally. Another option is to create a bootable CD with the assistance of the generated
diskettes that contains the boot diskette as well as the corresponding source for
installation.
In this chapter
Setup with Columbus Console and PXE ....................................... 19
Setup with boot diskettes.................................................................. 34
Setup with Columbus Console and PXE
Before you can set up a computer from the database with OS Deploy by using PXE, this
computer must be recorded in the database and its MAC address must be entered. The MAC
address of the network card is the only identification characteristic of a computer under
PXE.
19
Integrating computers by means of PXE
A further, very practical option for integrating a computer into the Columbus
administration is by means of a rollout using PXE (Preboot eXecution Environment).
To refresh computers by means of OS Deploy, switch on PXE on these computers (Preboot
eXecution Environment) and execute a PXE boot procedure. Insofar as your computer
supports the PXE standard, configure the BIOS of the computer in such a way that when it
starts up it sends PXE requests and the network card is the first in the boot sequence.
You can only try this function once. To do this, press the F12 key during the boot phase to
boot directly from the network card. Observe the message on the screen. It is possible that
you will have to choose another key or first switch on PXE in the BIOS.
For all PXE requests received, Columbus checks whether a system with the MAC address in
question is already recorded in the Columbus database. Basically two scenarios are possible
at this point:
The system is not recorded in the Columbus database
Columbus determines that no system with the MAC address in question has been recorded.
The computer is sent a special PXE image, which reads configuration details for the system
from the BIOS, automatically records the new system in the Columbus database and
transmits hardware information such as computer model, network and video cards, etc.
After this the system is switched off again.
By default, the new system will appear under Views - All inactive, in the Columbus
Management Console. The MAC address is given as the system name. No further
information is known during the PXE boot process. The Columbus administrator now needs
to rename and configure the new system accordingly. The computer can then be set up
again with OS Deploy.
The system was previously recorded in the Columbus database
Columbus determines that a system with the MAC address in question has already been
recorded in the Columbus database. Columbus then checks for possible outstanding
actions such as PowerON, operating system installation, software assignment, etc., and
performs these as defined. In a new system with an outstanding operating system
installation, installation of the relevant boot image and the subsequent installation of the
operating system are now started by means of PXE.
20
Columbus OSDeploy
Record computer manually
When recording a computer manually, the computer is set up manually in the Columbus
Management Console under a company or a specific site.
To do this, switch to the Display Workplace in the Columbus Console. In the tree structure,
highlight the company or site in which the new computer should be set up. Select the New
Computer function from the action menu or click on a blank space in the Computer window and
select the New action from the context menu.
Enter information about the new computer in the following template:
Abbildung 7: Computer hinzufügen
Name
NetBIOS name of the new system
Domain
NetBIOS domain name of the new system
MAC address
The MAC address (Media Access Control) is used by
Columbus for operation with PXE (PreBoot Execution
Environment).
Create Inactive
If this box is checked, the computer in question is
designated as inactive in the Columbus database.
Computers marked as inactive are not processed by
Columbus during operating system installation and
software distribution.
Chapter 2 Setting up computers
21
MAC address: It is recommended that you record the MAC address if you are considering
using PXE for staging of your clients. For example, manual recording of new clients in the
Columbus Management Console has the advantage that all the configuration steps
associated with a system rollout (e.g. determining the computer name, domain, client
config, assignment of operating system release, software, etc.) can be performed in
advance, and the rollout can be started manually or by means of a scheduler. If the new
systems are now started via wake on LAN and PXE, they can be identified by Columbus by
means of the pre-assigned MAC address, and be installed according to the planned
operations. See also Rollout via PXE (See "Integrating computers by means of PXE" on page
20).
22
Columbus OSDeploy
Selecting the Computer
After starting the console and selecting the Workplace tab, you can find the newly
registered computers in the Computers window after expanding the structure on the left
hand side and clicking on 'Computers' or 'All inactive'.
Abbildung 8: CMC Fenster Computers
Click in the Computers window to be able to call up the View item via the menu. This offers
various views. For example when you select 'Detail', the domain, cost center, status and
MAC address are displayed in addition to the computer name.
The Status column is only populated if you add the value _UDPPORT= 9880 to the
..\Programs\Columbus\Infrastructure\PXETemplates\oemparam.txt file. After this, a status
is displayed in the console by means of UDP, from which you can determine what the
computer is currently doing.
Chapter 2 Setting up computers
23
Staging one computer per console
Before installing an operating system, you need to give the computer a name. Computers
that have a MAC address only cannot be staged.
You can change the name of the computer by right clicking the computer and selecting
'Rename'.
Abbildung 9: CMC Rename Computer
Enter the desired computer name in the Machine field. In addition, a cost center can be
assigned here. A domain can be assigned by the Domain drop down menu; this can change
later though, e.g. if another domain is available in the release you selected.
After specifying the name, you must assign a release, a site and a config to the computer.
In order to describe the following instructions better, we assume that:
a release of WinXP and
a site MySite and
a config Generic exist with the corresponding file structure. This is in effect the default
configuration that exists after Columbus OS Deploy has been installed.
24
Columbus OSDeploy
Abbildung 10: CMC Release, Site und Config zuweisen
After you have assigned the release, site and config, you can perform additional settings via
'Configure'.
Chapter 2 Setting up computers
25
General
Abbildung 11: CMC Configure Reiter General
user data
User: The entry is assumed from the file
..\OSDepot\WinXP\Sites\MySite\Config\Generic\unattend.txt
Company: The entry is assumed from the
..\OSDepot\WinXP\Sites\MySite\Config\Generic\unattend.txt file.
Machine: The name that you have given the machine is assumed from the database
Operating system
release: The release that you selected for your machine in the 'Computers' window
Site: The site that you selected for your machine in the 'Computers' window
Config: The configuration that you selected for your machine in the 'Computers'
window
OS serial: ProductID is assumed from the file
..\OSDepot\WinXP\Sites\MySite\Config\Generic\unattend.txt
Region / location
Here you select a regional setting for your machine, for which you have created a
regional job.
26
Columbus OSDeploy
Network
Abbildung 12: CMC Configure Reiter Network
Network
Here you can select the affiliation of this machine to a domain or workgroup, or decide
whether the machine should be built 'standalone'. The relevant selections are made in the
file ..\OSDepot\WinXP\Sites\MySite\Config\Generic\choices.ini in the [Domains] and
[Workgroups] sections.
TCP/IP settings
Here you can select a TCP/IP template that has been stored in the file
..\OSDepot\WinXP\Sites\MySite\Config\Generic\tcpip.ini. If you use DHCP, you need not
make any changes here.
Chapter 2 Setting up computers
27
Hardware
Abbildung 13: CMC Configure Reiter Hardware
Input / output
Keyboard: Here you can specify the keyboard layout to be used. Selection options are
set in the file ..\OSDepot\WinXP\Sites\MySite\Config\Generic\Choices.ini, in the
[Keyboard] section.
Display: Here you can select the monitor resolution after completion of the setup.
Selection options are entered in the
file..\OSDepot\WinXP\Sites\MySite\Config\Generic\choices.ini, in the [DisplaySettings]
section.
Driver collections
Here you select the driver job required for your hardware.
28
Columbus OSDeploy
Jobs
Abbildung 14: CMC Configure Reiter Jobs
Mandatory jobs
Jobs whose installation on the computer is mandatory, are displayed here. This is done by
means of the entry Usage=Mandatory in job.ini of the corresponding job.
Optional jobs
Here you can click on, and thereby select optional jobs for this machine; several jobs can be
selected by pressing the CTRL key.
Partitioning
Partition: Here you can select one of the partition schemas that have been created in
the file ..\OSDepot\WinXP\Sites\MySite\Config\Generic\choices.ini, in the [Partition]
section.
Mode: Here you can select whether all (ResetAll) or only the boot partition(ResetFirst) of
the computer should be deleted prior to starting the setup. ResetFirst, for example, is
useful where machines are rebuilt and where the data in other partitions should be
preserved. If you select ResetFirst, the schema set under the partition is ignored, and
only the system partition is restored to the previous size.
Chapter 2 Setting up computers
29
SW management
Abbildung 15: CMC Configure Reiter SW Management
Columbus server
Here you can store an alternative configuration for the Columbus client where necessary, if
you use the Columbus software distribution mechanism. The corresponding entries must
be made in the file ..\OSDepot\WinXP\Sites\MySite\Config\Generic\Columbus.ini; every
section created ([text in square brackets is a section]) is displayed in the 'Manage by' drop
down menu, including the text.
30
Columbus OSDeploy
Method of installation
Abbildung 16: CMC Configure Reiter Installation Method
Method of installation
You can use this method to build up the computer with so-called images. The transmitted
source image must be contained in ..\OSDepot\WinXP\Images.
Click on 'Close' to complete the configuration.
Chapter 2 Setting up computers
31
Starting the installation
Abbildung 17: CMC Computers Window Deploy
Click on 'Deploy' to start the installation of the computer.
Abbildung 18: CMC Computers Deploy Zeitplan
You can select the timing of the installation in this window; for example, you can build up
the computer during the night when the network is not as busy.
By selecting the drop down menu in the Date field, you can set the date. You can enter the
time by means of the up/down keys or manually.
32
Columbus OSDeploy
Abbildung 19: CMC Select Date
Once you have applied your settings, click 'Install'. If you want the computer to be staged
immediately, click 'Install' without amending the date.
The Actions tab contains the actions that can be performed on the computer.
Abbildung 20: CMC Computers Reiter Actions
Name: Computer name
OID: The Object ID of the computer is displayed here
Action: The action to be performed by the computer is displayed here
poweron: Switching the computer on by means of the WoL command
preoscfg: Preparing the computer, partitioning the hard drive
osinst: Installing the operating system
Timer: Time after which the installation will be performed
Scheduled by: Name of the person who triggered the installation process
Scheduled at: When the installation process was triggered.
ActionID: ID of the action in the database
Chapter 2 Setting up computers
33
Setup with boot diskettes
If for any reason it is not possible, or required, to stage a computer by means of the
Columbus Management Console or PXE, you can set up the computer with boot diskettes.
The computer is then integrated into the Management Console by the Columbus client at
the end of the setup process.
If PXE is not used, OS Deploy is performed via the diskettes. These are created by means of
FloppyMaker and must be used locally. In this case the configuration is not performed via
the database, but via the Workstation Profiler. In this way, the computer profiles can be
predefined, or created only during setup.
This method is also particularly advantageous when setting up computers without network
connections. You have the option to create a bootable CD with the assistance of the
generated diskettes. The boot diskettes as well as the corresponding source for installation
will be on the CD. Application examples are laptops belonging to field service personnel,
home office workers etc. The CD can also be used as an emergency CD for mobile computer
repairs.
Creating a boot diskette
The Floppy Maker wizard guides you through the process required to create a boot diskette
for building a computer.
If required, you can extend the following functions of Floppy Maker.
Drivers required to enable the diskette to connect to a Windows or Netware Server, or
to execute OS Deploy from a CD or other local medium.
Additional keyboard layouts
Hard drive partitioning schemas
Parameter templates for different environments, e.g. different servers or IP segments
Diskette requirements
You require a standard 1.44 MB diskette to create the Windows NT/2000/XP Setup routine.
The diskettemust not be a bootable diskette
must not be blank
must not be formatted, as Floppy Maker can optionally also perform a quick format of
the diskette.
Note: All data on the diskette inserted will be overwritten
34
Columbus OSDeploy
Starting Floppy Maker
Execute floppymaker.exe with path ..\OSDepot\Support\FpyMaker to start Floppy Maker.
Abbildung 21: Floppy Maker - Start Screen
The Floppy Maker wizard appears, with the 'Generate a boot floppy' box already checked.
Click 'Next' if you want to create a boot diskette.
Chapter 2 Setting up computers
35
Selecting the boot image
Abbildung 22: Floppy Maker - Select Image
The Floppy Maker wizard presents you with selection options.
Images
When you use Floppy Maker for the first time, only the master
boot image is shown here. This image is a template that you still
need to use for performing additional configurations. After you
have compiled a boot disk according to your requirements, you
can create an image from this disk and make it available for
selection from this dialog. If you then select this image, you
must of course omit the modification of the configuration
(modify configuration settings)
Boot text
This allows you to provide a title for your boot diskette. This
function replaces the original MS DOS entry ("Starting
MS.DOS...") and is useful for providing boot diskettes with the
name of the computer, the release or the network adapter.
Unfortunately the text is limited to 18 characters.
Modifying
configuration
settings
If the image selected already contains all your settings, remove
the check mark and continue with the generation of the
diskette. Normally you will still need to define options so that
the boot diskette can be used in your environment.
The 'Next >' button takes you to the selection of the connection types.
36
Columbus OSDeploy
Selecting the connectors
Abbildung 23: Floppy Maker - Select Connector
This allows you to select the connection type to be executed with OS Deploy. You can use
CD-ROM drives, network devices, a JAZ or ZIP drive or the parallel connection of the
computer.
See the following chapter for an explanation of how to add a drive, if a required driver is
missing.
''Next >' takes you to the selection of the partitioning schemas.
Chapter 2 Setting up computers
37
Selecting the partitioning schema
Abbildung 24: Floppy Maker - Select Partitioning
If the partitioning schemas have been set up, all it takes is a mouse click to select the correct
one. The next chapter describes how to configure the template for partitions.
'Next >' takes you to the window in which you can select the keyboard layout.
Selecting the keyboard
Abbildung 25: Floppy Maker - Select Keyboard
Here you select the keyboard layout that you want to use in DOS mode.
'Next >' takes you to the last section, namely the selection of the configuration.
38
Columbus OSDeploy
Selecting parameters
Abbildung 26: Floppy Maker - Select Parameters
Finally, you must select the configuration parameters for your environment. Every
environment is defined by means of different parameters.
For example:
Server names
IP addresses
Passwords for connecting to the OS Deploy server
You can find an explanation as to how these parameters can be set in the next chapter.
Use'Next >' to create the diskette.
Chapter 2 Setting up computers
39
Create diskette
Abbildung 27: Floppy Maker - Create Diskette
Please insert a diskette in the A: drive of your local computer.
Floppy Maker needs a formatted diskette to be able to write an image to the diskette. We
recommend that you format every diskette before using it as a boot diskette. In this way,
you will avoid problems of 'old data' on the diskette.
If you activate 'Format boot disk' and click on 'Finish >', Floppy Maker performs a quick format
of the diskette inserted.
Alternatively, click on 'Finish >' and the diskette will be generated immediately.
40
Columbus OSDeploy
Format diskette
If you selected 'Format boot disk', you are now asked for options.
Abbildung 28: Floppy Maker - Format Diskette
Click on 'Start' to perform a quick format of the diskette.
Abbildung 29: Floppy Maker - Formatting Warning
If you are sure, click on 'OK'"
Abbildung 30: Floppy Maker - Formatting Not Possible
Please check the diskette, and remove the write protection if necessary.
Abbildung 31: Floppy Maker - Formatting Complete
Click on 'OK'"
Chapter 2 Setting up computers
41
Abbildung 32: Floppy Maker - Format Diskette
Click on 'Close'. Floppy Maker then creates the diskette.
Creating a boot diskette
Abbildung 33: Floppy Maker - Create Disk
This window displays the progress during the creation of the boot diskette.
42
Columbus OSDeploy
Boot diskette successfully created
Abbildung 34: Floppy Maker - Successfully Completed
Creation of the boot diskette has been completed. Click on 'Close' to exit the program.
Staging a computer by means of a boot diskette
You can find out how to create the appropriate boot diskette in the section 'Floppy Maker'
Chapter 2 Setting up computers
43
Introduction page
After you have created a boot diskette for your environment and machine type, you can
start Windows Setup. To do this, please insert the diskette in the diskette drive and start the
computer.
Abbildung 35: Welcome page
Select '1' to stage the computer. You can use option '2' to create an image of the computer.
44
Columbus OSDeploy
Partitioning
Abbildung 36: Partitioning
Select '1' if the partitions are to be created according to the schema selected in Floppy
Maker.
Select '2' if only the boot partition is to be reset (data in other partitions is preserved).
Select '3' to display partition information.
Select '0' to continue without partitioning. If you select this item, the boot partition must
already be formatted with FAT16.
View displayed if '1' is selected
Abbildung 37: Display of partitioning performed
After pressing a key the computer is rebooted and the installation proceeds.
Chapter 2 Setting up computers
45
View displayed if '3' is selected
Abbildung 38: Display of current partitioning
After pressing a key, you have the option to return to the previous menu or to exit the
program if you do not want to perform partitioning.
Selecting a release
This screen is displayed following the restart.
Abbildung 39: Release menu
Here you can choose different actions.
46
Reload/create disk images
Generate/recover copies of hard drives (partitions)
Service tools
Executing service tools (PartitionMagic, Norton Commander, etc.)
Help Text
Help for this menu
Columbus OSDeploy
Windows 2000 Professional
Workstation
Continue with the release for Windows 2000 Professional
Workstation
Windows 2000 Server
Continue with the release for Windows 2000 Server
Windows 2003 Server
Continue with the release for Windows 2003 Server
Windows XP Professional
Workstation
Continue with the release for WinXP Professional
Quit
Aborting the procedure
Profiler
The configuration of a computer is executed by a so-called Profiler, which accesses its data
from the OS Depot. Similarly, the configuration accesses its data via the console.
Selecting site and config
After selecting a release, the following screen is displayed.
Abbildung 40: Selecting release and config
Here you can specify the site and config that are to be valid for your computer. After making
your selection, proceed with 'Continue >>>'.
Chapter 2 Setting up computers
47
Designating the computer
Abbildung 41: Designate computer
Here you can select the computer that you want to configure or stage. If this is a new
computer, or your computer is not yet available, add the name to NEW and press 'Add'.
Then highlight the computer in the upper window and press 'Configure >>>' to configure the
computer.
If the computer has been previously configured and is already in the list, you can highlight
the computer and begin the setup by means of 'Start setup' without having to perform
further configuration.
If you need to set up a computer that is similar to one in the list, except for the name, you
can highlight the computer and select 'Clone'.
48
Columbus OSDeploy
General tab
Abbildung 42: Profiler tab General
User: The entry is assumed from the
..\OSDepot\WinXP\Sites\MySite\Config\Generic\unattend.txt file.
Organization: The entry is assumed from the
..\OSDepot\WinXP\Sites\MySite\Config\Generic\unattend.txt file.
License No. ProductID is assumed from the file
..\OSDepot\WinXP\Sites\MySite\Config\Generic\unattend.txt
Machine: The name that you have given the machine.
Location: Here you select a regional setting for your machine - a setting you have
created as a regional job.
Chapter 2 Setting up computers
49
Networking tab
Abbildung 43: Profiler tab Networking
Microsoft Networking
Here you can select the affiliation of this machine to a domain or workgroup, or decide
whether the machine should be built 'standalone'. The appropriate specifications are
entered in the file..\OSDepot\WinXP\Sites\MySite\Config\Generic\choices.ini in the
[Domains] and [Workgroups] sections.
Microsoft Networking client
This offers compatibility with earlier versions that can also be installed on Netware server.
50
Columbus OSDeploy
Protocols tab
Abbildung 44: Profiler tab Protocols
IP parameters
Here you can select a TCP/IP template that has been stored in the file
..\OSDepot\WinXP\Sites\MySite\Config\Generic\tcpip.ini. If you use DHCP, you need not
make any changes here.
Configuration tab
Chapter 2 Setting up computers
51
Abbildung 45: Profiler tab Configuration
Driver collections
Here you select the driver job that is suitable for your hardware.
Keyboard / display
Keyboard: Here you can enter the specification for the keyboard to be used. This is set in
the file ..\OSDepot\WinXP\Sites\MySite\Config\Generic\choices.ini in the [Keyboard]
section.
Display: Here you can select the monitor resolution after completion of the setup.
Selection options are entered in the
file..\OSDepot\WinXP\Sites\MySite\Config\Generic\choices.ini, in [DisplaySettings]
section.
52
Columbus OSDeploy
Jobs tab
Abbildung 46: Profiler tab Jobs
Optional jobs
Click here to select optional jobs for your machine. You can select multiple jobs by pressing
the CTRL key.
Mandatory jobs
Jobs whose execution on the computer is mandatory are displayed here. This is done by
means of the entry Usage=Mandatory in job.ini of the corresponding job.
Chapter 2 Setting up computers
53
Extras tab
Abbildung 47: Profiler tab Extras
System partition
Leave FAT: Leave partition with FAT formatting (not recommended)
Convert to NTFS -> extend by (KB): Convert partition to NTFS and extend the partition
to the maximum size available (recommended setting).
Build options
Here you can set whether the license agreement should be displayed during the
installation.
54
Columbus OSDeploy
SW distribution tab
Abbildung 48: Profiler tab SW Distribution
Distribution templates
Here you can store an alternative configuration for the Columbus client where necessary, if
you use the Columbus software distribution mechanism. The appropriate entries must be
made in the file ..\OSDepot\WinXP\Sites\MySite\Config\Generic\Columbus.ini. Every
section ([text in square brackets is a section]) is displayed with the text in the drop down
menu.
Chapter 2 Setting up computers
55
About tab
Abbildung 49: Profiler tab About
The configuration you have just created is saved using 'Save profile'. You can then use
'Close' to exit the dialog. The installation is then started.
56
Columbus OSDeploy
Emergency diskette
After completing the configuration, you can select whether you want the inserted diskette
to be converted into an emergency diskette.
Abbildung 50: Request for emergency diskette
If you select '1 - Make this floppy an emergency disk', the computer profile is stored on the
diskette, so that the computer can be rebuilt with this diskette without any user entry. The
following screen then appears.
Abbildung 51: Emergency diskette created
Press any key to continue...
Chapter 2 Setting up computers
57
Completing the configuration
If you set the parameter _RequestName to 'T' in params.txt, the system asks you for the
name of the person performing the processing.
Abbildung 52: Request for operator
After you have entered your name, you are asked to remove the diskette.
Abbildung 53: Request to remove inquiry diskette
The Windows installation begins after the diskette has been removed.
58
Columbus OSDeploy
Floppy Maker
By using Floppy Maker, it is possible to create boot diskettes for computers that are not PXE
capable (..\OSDepot\Support\FpyMaker\floppymaker.exe). In addition, it is possible to
create an image from a diskette, which can then be used to create a boot CD, for example.
Creating a boot diskette image
Not only can you create boot diskettes with Floppy Maker, you can also create images from
these diskettes.
We recommend that you create an image of every boot diskette used in production. This is a
big time saver, especially where you are creating multiple diskettes.
Generating the image
Please start FloppyMaker and select 'Store boot disk on harddisk'.
Abbildung 54: Floppy Maker - Start Screen
Continue with 'Next >' ...
Chapter 2 Setting up computers
59
Naming the image
Abbildung 55: Floppy Maker - Name Image
Here you can give the image to be created a name; you can also see which images are
already available.
Click on 'Next' > to continue.
60
Columbus OSDeploy
Insert diskette
Abbildung 56: Floppy Maker - Insert Disk
Please insert the diskette from which you want to create an image and click on 'Finish'"
Abbildung 57: Floppy Maker - Create Image
Progress during a creation process is displayed here.
Chapter 2 Setting up computers
61
Image successfully created
Abbildung 58: Floppy Maker - Create Image Complete
The creation was successful; click 'Close' to exit the program.
62
Columbus OSDeploy
CHAPTER 3
Getting to grips with OS deployment
In this chapter
Configuration......................................................................................... 65
Migration of AutoSetup environmments .................................... 99
Configuring infrastructure services ............................................... 102
Pre-Boot Execution Environment (PXE) ........................................ 107
Troubleshooting OS deployment.................................................... 113
Hard disk images................................................................................... 118
Security..................................................................................................... 123
63
CHAPTER 4
Configuration
By means of simple utilities, OS Deploy can be adapted in such a way that the optimal result
for you is always achieved - in this case the optimally configured computer.
The following pages describe tasks for the releases, jobs, sites and configs, and how you can
achieve your desired result.
In this chapter
Structure .................................................................................................. 66
Releases.................................................................................................... 67
Sites & configs ....................................................................................... 68
OS Deploy jobs ....................................................................................... 76
Configuring Floppy Maker ................................................................. 86
65
Structure
All data required for OS Deploy are available in an ordered structure on the Columbus
server.
After a standard installation you can find the OS Depot directory in the Columbus release
(unless the name has been changed). This contains all required configuration files, the
setup source etc.
Abbildung 59: OS Deploy folder contents
Quit
Used for internal functions of OS Deploy. No settings are possible here.
computer.img
This must contain ghost.exe from Norton Ghost, for example, if the imaging function of OS
Deploy is used.
Service
The tools for the so-called service boot are stored here. You can use the service boot to
perform particular functions in the client, such as changing partitions, for example.
Support
66
Columbus OSDeploy
The Support directory contains tools and programs that you need for working with OS
Deploy, including Floppy Maker and both password encryption programs cryptit.exe and
publicrypt.exe (in the Tools subdirectory)
Win2000, Win2000.Srv, Win2003.Srv, WinXP
These directories contain the corresponding OS Deploy releases. The configuration of the
individual releases also takes place here. Please note that you can only stage server
operating systems with the Columbus Enterprise edition.
Files
The files contained in the directory are required for the functions of OS Deploy. You cannot
change the configuration here.
Releases
As described in the previous section, the actual releases that can be used for staging are
contained in the Win2000, Win2000.Srv, Win2003.Srv and WinXP directories. In principle,
you can rename these directories. It is important, however, that you adhere to the 8.3
notation and do not include any special characters.
Directory / file
Description
<WinXP>
Example of a release directory This directory can be
named as desired, as long as the 8.3 notation
standard is observed.
Release.txt
This file contains text that is displayed in the
console instead of the restricted (8.3) directory
name, e.g.
Windows XP Professional Workstation
This is particularly important if you have multiple
releases of the same operating system, e.g.
Windows XP with SP1, Windows XP with SP2, or
even different language versions.
Images
This directory must contain the file ghost.exe to be
able to use the imaging process in OS Deploy. The
images that were created with OS Deploy are also
stored in this directory. If you have set up a
computer completely, for example, and want to be
able to recover it quickly by means of imaging, the
appropriate file is stored here.
Caution: Image files can be several GB in size. If you
use images, please ensure that you have sufficient
space.
Chapter 4 Getting to grips with OS deployment
67
Job
License
OS\I386
source.ini
Setup
profiler.exe
Profiler.bmp
Sites
The jobs assigned to the release are stored in this
directory. This can be driver jobs, jobs for particular
settings, etc. A detailed description is provided in
the next section.
This directory contains your Columbus license,
which is checked at every OS Deploy execution. The
license is stored in this directory by default by the
installation program.
This directory contains the i386 directory of the
corresponding CD of the operating system. You
must copy the i386 directory, including all files and
possible subdirectories to this directory, if this did
not occur during installation.
If your operating system is a server version, you
must enter this in source.ini:
[Source]
I386 = server
;I386= Workstation
Contains a mini Windows 3.11 that allows you to
use a convenient interface when using a boot
diskette.
A graphic front end that allows you to collect the
data for a computer after booting with a boot
diskette.
This bit map is displayed when the Profiler is called
up. It can be modified to your corporate design.
Contains the configuration settings for different
locations or environments as well as the profiles
created by the Profiler. These enable a reinstallation to be performed easily.
Sites & configs
The Release directory contains a Sites directory, which is intended to make the
administration of different locations containing different configurations easier. These
different configurations can be stored in this directory.
Possible settings are described in the following entries.
Structure
Sites
68
Columbus OSDeploy
This is the base directory used for storing all sites.
<SiteName>
Config
<Config Name>
Choices.ini
Columbus.ini
Using this directory, you can start a new site, so to speak.
This could be a country (Switzerland, France, etc.) or also a
branch within a country for example, where multiple
branches exist. When you create a new site, simply copy the
directory of another site and make the necessary changes.
Contains different pre-defined configuration templates
Name of the configuration template
Contains the selection options for configuring the computers
in the console or in the Profiler
Contains configuration templates for the Columbus
Management client, in case the client is to be distributed
with OS Deploy.
Options.ini
Contains special configuration settings for OS Deploy
services.
TCPIP.INI
Contains pre-defined IP templates, in case fixed IP addresses
are used instead of DHCP.
Microsoft control file for Unattended Setup
Unattend.txt
Profile
This directory contains the configuration files for OS Deploy,
in case you need to stage computers with the assistance of
Floppy Maker.
$wslist$
The file $wslist$ contains the computer names and the WSID of a computer, if a computer has been configured with the
Profiler.
WS<nn>.txt
This file contains an automatically generated Unattend.txt
file according to Microsoft standards. You can establish from
the $wslist$ file for which computer this file was generated.
WS<nn>.ini
The file contains an automatically generated options.ini,
which contains the configuration options of the
corresponding computer. You can establish from the
$wslist$ file for which computer this file was generated.
Chapter 4 Getting to grips with OS deployment
69
choices.ini
Various specifications concerning monitor settings, available domains and workgroups,
time zones, keyboard layouts etc. can be made in the choices.ini file. The options selected
are for the most part transferred to the unattend.txt file. Domain membership is
transferred to the options.ini (not in this directory, but rather one set up during staging), as
the 'domain join' by means of an OS Deploy is regarded as more reliable. If the network
connection to the domain controller is unreliable, the OS Deploy job will make multiple
attempts.
Examples:
[Partition]
Full Disk=REST/NTFS
3gb - Rest=3000/NTFS,REST/NTFS
8gb - Rest=8000/NTFS,REST/NTFS
4gb - 4gb - 2gb - Rest=4000/NTFS,4000/NTFS,2000/FAT,REST/NTFS
In the specifications of the Partition section, the part before the equals sign is displayed as a
selection in the Jobs tab in the OS Deploy console. The required partitioning can be entered
thereafter.
[DisplaySettings]
XGA (1024x768, 85 Hz, 64k Colors)=1024,768,85,16
XGA (1024x768, 70 Hz, 64k Colors)=1024,768,70,16
XGA LCD (1024x768, 60 Hz, 64k Colors)=1024,768,60,16
SVGA (800x600, 70 Hz, 256 Colors)=800,600,70,8
VGA (640x480, 60 Hz, 16 Colors)=640,480,60,4
Special (1152x882, 72 Hz, 32k Colors)=1152,882,72,15
Special (1152x882, 85 Hz, 32k Colors)=1152,882,85,15
UXGA (1280x1024, 60 Hz, 32k Colors)=1280,1024,60,15
UXGA (1280x1024, 85 Hz, 32k Colors)=1280,1024,85,15
HIRES (1600x1200, 85 Hz, 32k Colors)=1600,1200,85,15
Specifications as to what resolution, screen refresh frequency and color depth the monitor
should have after completion of Microsoft Windows Setup can be entered in the Display
Settings section. The selection is performed in the Hardware tab in OS Deploy via the
console.
[Domains]
;Password may be encrypted with publiccrypt.exe
;If joining causes problems on some machines, it is possible to include the name
of the domain controller
;Using DNS names instead of NetBios can also reduce domain joining problems. DC
may not be specified in this case
; DomainAlias=Domain,Account,Password
; DomainAliasWithDC=Domain\server,Account,Password
; DomainAliasWithOU=Domain,Account,Password,OU=Company,OU=Department,DC=Group
; CryptedDomainAlias=Domain,Account,H#692635EF5ADF201EC8
Different domains, which can later be joined by the computer, can be made available. The
corresponding OU in which the computer should be accommodated can also be entered, on
request. A different combination of account and password can be entered for every domain.
If problems are experienced when adding these, a DC on which the registration is
performed directly can also be entered. In this case, it is not necessary to search for a
domain controller. The password can be encrypted by means of the publicrypt.exe
(..\OSDepot\Support\Tools\publicrypt.exe) program
[Keyboard]
Switzerland (German)="0807:00000807"
Switzerland (French)="100c:0000100c"
Switzerland (Italian)="0810:00000410"
Switzerland (all keyboards)="0807:00000807","100c:0000100c","0810:00000410"
Germany="0407:00000407"
Argentina="2c0a:0000080a"
Spain (Traditional)="040a:0000040a"
Taiwan="0404:00000404"
70
Columbus OSDeploy
Thailand="041e:00000409"
Turkey="041f:0000041f"
United Arab Emirates="3801:00000409"
United Kingdom="0809:00000809"
United States="0409:00000409"
The layouts of the keyboards connected to the computers are determined here. Please use
valid entries from the documentation for the unattend.txt file. This can be found on your
Windows product CD.
[TimeZones]
Switzerland/Germany = "110"
The values for the time zones required are entered here.
[Workgroups]
NTSETUP=NTSETUP
Workgroup=Workgroup
If you do not want the computer to join a domain, you can enter one or more workgroup
names as an alternative here.
Important: All information concerning unattend.txt can be found on your Windows product
CD or the Microsoft web site.
Chapter 4 Getting to grips with OS deployment
71
Columbus.ini
The settings for the Columbus client are entered in the Columbus.ini file, insofar as these
have been installed on the computer in question.
Detailed information about configuring the Columbus client can be found in the manual
'Columbus 6 - First Steps'
[My Columbus Environment]
;COMMENT: account used by the Columbus client to connect to SW Depot and to
install SW packages (will be local admin on client computer)
Domain=
User=Columbus
;COMMENT: Create encrypted passwords with the utility cryptit.exe (Columbus 5
style, example: Password=H#B777973B2483E148B95B1086E9D8B3DD3C52)
Password=H#B777973B2483E148B95B1086E9D8B3DD3C52
Specifications by which the Columbus client connects to the Software Depot responsible for
the client are entered here. If a domain user is entered as a user, this user is added to the
local group of administrators. If the user is not a domain user, an account is created on the
computer and added to the administrators group. Encrypting of the password is performed
using cryptit.exe. Ensure that the H# is present at the beginning of the password.
;COMMENT: Path to the software administration area
;only needed for C5 compatibility. Necessary if %_AdminPath% has been used in
packages, e.g. for path to config files
;example: SWAdmin=\\MyServer\ColumbusShare\Admin
SWAdmin=
;COMMENT: If LocalApplications is not set, the default path for 'Program Files' is
used
;LocalApplications=%_ProgramFiles%
;COMMENT: If Cache is not set, the default points to c:\windows\cache\
;Cache=%_Windows%\Cache\
;COMMENT: DefaultApplServer is only needed when packages are installed on the file
server for shared usage
DefaultApplServer=
Here different characteristics of the Columbus client are specified, e.g. the location of the
Software Administration Area (only required for compatibility with Columbus 5) and the
local Package Cache etc.
Options.ini
The options.ini file and the unattend.txt file form the computer profile that is required for
setting up the computer. The unattend.txt file contains all settings for the Windows setup,
and the options.ini contains all settings and specifications that the OS Deployment service
needs for execution of its scripts when setting up a new computer.
The options.ini file is also used for pre-selecting certain parameters in the configuration
dialog. You can enter options from the choices.ini file in the Defaults section. These options
are then already selected when a new computer is configured.
Important:
The local administrator password is defined in this file.
The specifications for the Columbus database must be entered correctly, so that the OS
Deployment service and the Columbus client function correctly on the new computer.
72
Columbus OSDeploy
Entries in options.ini
[Defaults]
DomainAlias=MYBWDOMAIN
ResolutionAlias=XGA LCD (1024X768, 60 HZ, TRUE COLOR)
The default values for domain selection and screen resolution for the Profiler can be set
here. These parameters are not supported in the console.
[Defaults]
Domain=MYBWDOMAIN
Workgroup=
Display=XGA LCD (1024X768, 60 HZ, TRUE COLOR)
Keyboard=SWITZERLAND (GERMAN)
PartitionLayout=20 GB - Rest
PartitionMode=ResetFirst
RegionJob=R_SWISS.GE
IPTemplate=DHCP
DriverJob=HPD530
Various default values can be set here for the OSDeployment configuration dialog in the
console . These parameters are not supported by the Profiler.
[Administrator]
; Specify password for local administrator
; Create encrypted passwords with the utility cryptit.exe (found in the folder
OSDepot\Support\Tools)
Password=H#B777973B2483E148B95B1086E9D8B3DD3C52
The password for the local administrator is set here. The encryption of the password is
performed by cryptit.exe. Ensure that the H# at the beginning of the password is present.
[Impersonation]
; If a Setup service is required for impersonation, the following options must be
specified
; Create encrypted passwords with the utility cryptit.exe (can be downloaded from
www.brainware.ch)
Domain=
User=
Password=
A user account can be entered in the [Impersonation] section. The OS Deploy service will
execute its jobs in this context.
; Data of the default domain to be joined
[JoinDomain]
Domain=
User=
Password=
The default values for a domain can be stored here. These are then used by default in the
Profiler.
[Columbus]
;Default: company for computer auto registration. Needed if multiple companies are
defined in the console
Company=Brainware Solutions
The standard company to which a client is added is set up here.
[database]
DBHost=C6
DBFile=C:\Columbus\database\Columbus.fdb
DBUser=columbusrw
DBPW=H#B777973B2483E148B95B1086E9D8B3DD3C52
AuditDBHost=C6
AuditDBFile=C:\Columbus\database\BWlogging.fdb
AuditDBUser=columbusrw
AuditDBPW=H#B777973B2483E148B95B1086E9D8B3DD3C52
The specifications with which the OS Deploy service can connect to the database are
entered here.
[Jobs]
R_SWISS.GE=1
Chapter 4 Getting to grips with OS deployment
73
You can pre-select jobs by entering them in the [JOBS] section, in the format Directory
name=1 (also for those jobs not designated as 'Mandatory').
tcpip.ini
You can create predefined TCP/IP templates in this file. These are then available in the OS
Deploy console in the Networking tab. Using DHCP is the most straightforward - you won't
need any templates.
The selected entries are transferred to unattend.txt during staging.
;
;
;
;
;
;
;
;
;
;
;
==========================================================================
(c) Copyright 1998-2003 by Brainware Consulting & Development
www.brainware.ch
==========================================================================
Filename : tcpip.ini for Windows NT4/2000/2003/XP
Directory : ..\[Site]\Config\[Configuration]
Description : Options available in drop down boxes
Add or modify templates and entries according to your needs
Delete templates that are not required
Version : 6.00
==========================================================================
[DHCP> Example]
DHCP=1
IP=
Subnet=
Gateway=
PrimaryWins=
SecondaryWins=
DNSName=
Scope=
DNSServer1=
DNSServer2=
DNSServer3=
[Fixed IP Example]
DHCP=0
IP=10.1.1.x
Subnet=255.255.255.0
Gateway=10.1.1.1
PrimaryWins=10.1.1.5
SecondaryWins=
DNSName=
Scope=
DNSServer1=
DNSServer2=
74
Columbus OSDeploy
unattend.txt
This is the standard Microsoft Windows unattend.txt file that is created with Setup
Manager (setupmgr.exe on the Windows product CD).
Generally, this file consists of sections and keys that are assigned parameters. Most sections
are predefined; some can, however, be extended by the user.
You should specify the following in this file
FullName (standard user displayed in the console)
OrgName (standard company displayed in the console)
ProductID (If you entered the license number during the installation of Columbus, this
entry already exists.)
Please consult the appropriate Microsoft documentation on your product CD or the
Microsoft web site for further information on the unattend.txt file.
;SetupMgrTag
[Data]
AutoPartition=1
MsDosInitiated="0"
UnattendedInstall="Yes"
[Unattended]
UnattendMode=FullUnattended
UnattendSwitch=Yes
OemSkipEula=Yes
OemPreinstall=Yes
DUDisable=Yes
TargetPath=\WINDOWS
FileSystem=ConvertNTFS
ExtendOEMPartition=1
[GuiUnattended]
AdminPassword="*"
EncryptedAdminPassword=No
OEMSkipRegional=1
TimeZone=110
OemSkipWelcome=1
[UserData]
Full name="User"
OrgName="Brainware Solutions"
ComputerName="MyComputer"
ProductID="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
[TapiLocation]
CountryCode=41
; Dialing=Tone
; AreaCode=041
[RegionalSettings]
LanguageGroup=1
SystemLocale=00000807
UserLocale=00000807
InputLocale="0807:00000807"
[SetupMgr]
; DistFolder=c:\winxpdist
; DistShare=winxpdist
[Identification]
JoinWorkgroup=AUTOSETUP
[Networking]
InstallDefaultComponents=No
[NetAdapters]
Adapter1=params.Adapter1
[params.Adapter1]
INFID=*
[NetClients]
MS_MSClient=params.MS_MSClient
[NetServices]
MS_server=params.MS_server
Chapter 4 Getting to grips with OS deployment
75
[NetProtocols]
MS_TCPIP=params.MS_TCPIP
[params.MS_TCPIP]
DNS=No
UseDomainNameDevolution=No
EnableLMHosts=Yes
AdapterSections=params.MS_TCPIP.Adapter1
[params.MS_TCPIP.Adapter1]
SpecificTo=Adapter1
DHCP=Yes
WINS=Yes
NetBIOSOptions=0
OS Deploy jobs
OS Deploy gives you the option to influence the Windows installation before or after the
actual setup. During the staging of computers, you can select so-called jobs that perform
tasks that cannot be executed by Windows Setup. These are, for example, changing registry
settings, executing computer configurations, adding users or installing drivers that are not
automatically recognized.
Note: The 8.3 notation for directories and files is also relevant here. These jobs are executed
in DOS mode, or are copied in DOS mode.
Job components
Every job must contain a definition file (job.ini). The remaining structure depends on the
functions required from the job.
Setting up job.ini
This file mainly defines under which name and where in the console the job is to be
displayed.
Syntax
[Identification]
Title=<Text>
Type={COMMON|COLLECTION|REGIONAL|SERVER}
Usage={OPTIONAL|MANDATORY}
76
Entry
Value
Meaning
Title
<Text>
Name shown in the console.
Type
COMMON
Common jobs are shown in the Jobs
tab in the console. This type of job can
contain any type of action.
Columbus OSDeploy
Usage
;
COLLECTION
Collections contain driver packages
for particular computers, such as
video, sound and network drivers, for
example. There should be one job per
hardware model, such that the job
contains the driver for this model. You
can select these jobs in the Hardware
tab in the console.
REGIONAL
Regional jobs determine settings such
as time zones and TAPI zones. These
jobs can be found in the General tab
in the console. The settings selected
are stored in the unattend.txt file.
OPTIONAL
These jobs are optional, and do not
have to be installed.
MANDATORY
These jobs must be installed - they
cannot be deselected. For example, if
you supply all jobs whose installation
is mandatory on every computer with
this parameter, you will not be able to
'forget' them.
(remark)
Lines beginning with a semicolon are
comment lines.
Example
[Identification]
Title=My First Job
; For selection in the jobs list in the console, using above title
Type=COMMON
; usage defines if the job can be de/selected (optional) or if it will always be
installed (mandatory)
; Usage=Optional
Usage=Mandatory
Naming standards
Every job must be stored in the directory ..\OSDepot\Release\Job\.. The directory names
must adhere to 8.3 notation, as they are copied in DOS mode to the hard drive of the
computer to be staged. The number of jobs can be large, and the number of available letters
is restricted. Consequently, we provide some suggestions as to the naming convention for
the directories.
Most jobs created by Brainware are named according to this specification. You can,
however, use your own standards at any time.
You can use our Job Manager Tool tool (..\OsDepot\Release\Job #\jobmgmt.exe) to get an
overview of the jobs.
Syntax:
I_XXXXnn
Chapter 4 Getting to grips with OS deployment
77
Letter
Description
I_
Indicator of the type of job
XXXX
c
Common or configuration jobs
r
Regional job (time zone, etc.)
s
Driver package for a particular hardware model
Abbreviation for the functionality of the job or the
hardware manufacturer - max. 4 characters.
Example: CPQ, IBM, DELL, HP, BW
nn
Running number to differentiate between identical jobs.
Additionally, the three letters after the period can be used for further identification.
Example: s_IBM01.drv, R_Swiss.fr, R_Swiss.ge
Pre-setup processing
This part of a job is executed before the Windows installation is started.
File / directory
Description
insert.txt
The insert.txt file adds the lines defined in each section
to the unattend.txt file.
replace.txt
The file replace.txt replaces complete sections of the
unattend.txt file with those named in this file.
special.bat
The file special.bat executes special actions after the
contents of the $OEM$ and $ directories have been
copied to the C: drive.
Zipped driver packages are often copied to the system
drive with the assistance of this file. In this way the
limitations of path and file name length can be
overcome.
ASETUP
$OEM$
If the directory Asetup exists, it is copied to the system
directory. This directory contains OS Deploy scripts that
will be executed later under Windows.
If this directory exists, the contents of the directory are
copied to the system drive (C:). The contents of
subdirectories are automatically integrated into the
Windows Setup program.
All the files/directories mentioned above can exist in a job, although this is not compulsory.
78
Columbus OSDeploy
Microsoft OEM extensions
The Microsoft OEM extensions were created to extend Windows Setup functionality. Please
read the appropriate Microsoft documentation describing how this structure can be used.
$OEM$
If this directory exists in a job, its contents will be copied to
the system drive to C:\$.
The contents of subdirectories are automatically
integrated by Windows Setup at installation.
Because $OEM$ gets copied to C:\$ anyway, you may
simply use $ in an OSDeploy job instead of $OEM$.
$1, $2, $3
Files in this directory are copied to the 1st, 2nd, 3rd ... drive
(C:, D:, E:... ).
Windows 2000/XP support multiple system drives. If you
already have a Windows installation on C: and want to
copy data to D:, you must use $2.
This is only applicable to Windows 2000/XP.
$$
Files in this directory are copied to the system directory
(e.g. C:\WINNT) before the setup starts the graphic section
of the installation.
$$\system32
C, D
Text modes
Files in these directories are copied to C: or D:D: .
Files in this directory are copied to the temporary setup
directory on the system drive, so that the setup can use
these files when the text based section of the setup starts.
In this way, you can integrate SCSI or RAID drivers that are
needed right at the beginning of the setup.
Note: The directories $1, $$, C, etc. Text modes must be subdirectories of $OEM$ or $, so
that the functionality can be ensured.
Post setup processing
These files are executed after the Windows Setup of the OS Deploy service has been
completed.
ASETUP
<Name>.wms
If this directory exists, the contents are copied to the
system drive C:. This directory contains the OS Deploy
scripts.
OS Deploy scripts that are executed after the Windows
Setup of the OS Deploy service has been completed.
The scripts are executed in alphabetical order and are
deleted after processing. The OS Deploy service uses
the Columbus Script Engine. Consequently, all
Columbus commands can be used.
Chapter 4 Getting to grips with OS deployment
79
Creating a job
Here we describe how to create different jobs, by means of examples.
Driver job
In Windows 2000 and XP you have the option of a Plug & Play driver installation. This type
of installation allows for easy integration of drivers of so-called Plug & Play hardware in OS
Deploy. All you need to do is to copy the drivers to the Drivers directory in the system drive.
The unattend.txt file must then be extended by one entry so that Setup searches the
named directory for the drivers during installation.
Once Windows Setup is running, Plug & Play capable hardware is identified (this can take
up to 20 mins) and the correct drivers are traced. If Windows Setup is unable to find the
correct driver in its database, it will search the Drivers directory. Windows is able to select
the hardware by means of the unique Plug & Play identifier. Setup can then install the
correct driver (*.INF file) for this hardware.
Hardware that is not Plug & Play capable can also be supplied with drivers by means of OS
Deploy scripts.
Driver job structure
The directory name of the job in 8.3 notation. The more jobs
Job directory you have, the more difficult it is to select corresponding
(here S_MyPC01) directory names.
The entire structure of a driver job is contained in the
directory $OEM$; it could also simply be called $.
job.ini
The identification file for the job is job.ini. Except for the
title, all other entries for driver jobs are identical to those in
Windows2000/XP.
[Identification]
Title=Description of the computer model
Type=COLLECTION
Usage=OPTIONAL
insert.txt
The insert.txt file contains the specifications that must be
added to the unattend.txt file.
The variable OemPnPDriversPath shows Setup an alternative
path in which drivers can be found if no matching drivers are
found in the driver database. Only directories listed here are
searched.
[Unattended]
DriverSigningPolicy = Ignore
OemPnPDriversPath = "Drivers\Audio;Drivers\Net;
Drivers\Video;Drivers\Power;Drivers\Input;Drivers\Mode
m;Drivers\Others"
80
Columbus OSDeploy
$OEM$\$1
Files in this directory are copied to the system drive
(normally C:).
Drivers
The Drivers directory must exist in the C:\ drive ($1) with
exactly the same name.
In some knowledge base items, Microsoft recommends
creating subdirectories for every driver type. In this way
problems where different drivers have the same file name
can be avoided.
Each of these directories must be defined in the variable
OemPnPDriversPath in the unattend.txt file (or in the job insert.txt).
Use the same directory structure for every driver job; this
minimizes errors and allows for simple porting to other
systems.
Brainware driver jobs use the following directories.
Audio
Input
Modem
Net
The directory for audio drivers
The directory for input device drivers, such
as pointing devices, touch pads or special
keyboards
The directory for modem drivers
The directory for network card drivers
Others
The directory for drivers that are not
suitable for any of the other directories
Power
The directory for power management
drivers
Video
The directory for graphic card drivers
Chapter 4 Getting to grips with OS deployment
81
Creating a driver job
Collect all the drivers required for your computer model. These drivers can mostly be found
on the CDs supplied or on the manufacturer's web site. Use only current drivers, to avoid
problems. At time of delivery, larger companies such as HP or IBM have already made more
current drivers available on their web site.
Create the necessary directory structure, or copy the job s_new.drv, which is available as a
template in every job directory.
Edit the file job.ini and label the job with a meaningful name for your hardware.
Copy the driver files to the relevant directories.
Copy network card drivers to the Net directory,
graphic card drivers to the Video directory
etc.
Drivers are not installed with their setup programs (Setup.exe) during Plug & Play detection
(these are provided for installation by the end user). Rather, *.inf is executed. You can
therefore omit the setup programs (setup.exe) and in this way preserve space in your driver
job.
Windows 2000, and in particular Windows XP, setup programs prefer signed drivers. This
means, drivers must originate from a Microsoft test laboratory. A signed driver contains a
*.cat file; by double clicking this file, a certificate is displayed. Although we set
DriverSigningPolicy=Ignore in the job (see insert.txt) so that unsigned drivers can also be
installed, these are not installed by the setup program in some cases. To a large extent,
however, hardware manufacturers make signed drivers available.
Your job is now ready for testing.
82
Columbus OSDeploy
Optimizing a driver job
Some driver jobs can be fairly comprehensive. You can compress the driver job by means of
a ZIP tool (e.g. WinZIP) to save time during the copy procedure and to avoid problems with
DOS restrictions (8.3 notation, path length, number of subdirectories).
Create a Zip File of the Drivers directory, named 'drivers.zip'. It is important that the Drivers
directory itself is contained in the ZIP file, in order to unzip the file into the correct directory.
Next, create a file called special.bat, containing the following.
@echo off
echo ... expanding drivers
c:>nul
cd \>nul
pkunzip -d %1\drivers.zip>nul
During execution, the batch file switches to the system drive (C:) and unzips the ZIP file
there. Because the Drivers directory is contained in the ZIP file, directories such as the
following result - C:\Drivers\Audio, C:\Drivers\Net etc.
The batch file copies (unzips) the drivers directly to C:\Drivers and not to C:\$\$1\Drivers, as
would be necessary for Microsoft OEM functionality. For this reason, the setup procedure
need not copy the data from C:\$\$1\Drivers to C:\Drivers. The result is thus the same.
Your job would then consist of the following elements.
The file job.ini contains the appropriate title for the job.
job.ini
insert.txt
drivers.zip
The insert.txt file adds the entries for the unattend.txt file,
which defines the OemPnPDriversPath.
The drivers in a zipped file.
The batch file for unzipping the ZIP file.
special.bat
You can find examples of this file in the s_new.drv job template. This also contains the
appropriately packed drivers.zip file.
Regional job
Microsoft's Unattended Setup allows you to define locality-dependent parameters such as
country settings, time zones, dialing rules etc. in the unattend.txt file.
You can simply create one OS Deploy job for every region to avoid having to create multiple
unattend.txt files for different regions.
These jobs are displayed in the General tab in the OS Deploy console.
Regional jobs are very similar to driver jobs. Every job must have a definition file (job.ini) and
an insert.txt file that contain the data that needs to be added to the unattend.txt file.
Chapter 4 Getting to grips with OS deployment
83
Structure of a regional job
Jobfolder
job.ini
The directory name for the job in 8.3 notation. Where
there are many regional jobs, it is possible that cryptic
directory names can occur, such as R_USA, R_SW,
R_German, R_Swiss.fr, R_Swiss.ge
The identification file of the job must contain the
following entries. The title of every job is different. The
other entries are identical for Windows 2000/XP.
The title is displayed in the General tab in the console in
OS Deploy.
[Identification]
Title=<Land or Standort>
Type=LOCATION
Usage=Optional
insert.txt
This file contains the settings that are transmitted to
the unattend.txt file when the job is selected.
Example: insert.txt for German settings
[GuiUnattended]
OEMSkipRegional=1
TimeZone=110
[TapiLocation]
CountryCode=49
[RegionalSettings]
LanguageGroup=1
SystemLocale=00000407
UserLocale=00000407
Example: insert.txt for French settings.
[GuiUnattended]
OEMSkipRegional=1
TimeZone=105
[TapiLocation]
CountryCode=33
[RegionalSettings]
LanguageGroup=1
SystemLocale=0000040c
UserLocale=0000040c
The entries for unattend.txt can be defined using the Microsoft Setup Manager, which can
be found in the Tools directory on the Windows 2000 or XP CD. You may have to install the
deployment tools using the instructions in the readme files.
You can, however, also perform the settings manually. Please read the documentation on
the unattend.txt file on the Windows product CD for further information.
84
Columbus OSDeploy
Administering OS Deploy jobs
Due to directory restrictions (8.3 notation), most jobs have cryptic directory names. A Job
Manager, which provides a better overview of the jobs, can be found in the Job directory.
The Job Manager provides an overview of all jobs including the description, and also allows
jobs to be switched between 'Mandatory' and 'Optional'.
Abbildung 60: Job Manager window
The View menu item allows you to sort the jobs according to different criteria.
Abbildung 61: Job Manager sorting
The Edit menu point allows you to toggle the job status between 'Mandatory' and
'Optional'.
Abbildung 62: Job Manager toggle use
Chapter 4 Getting to grips with OS deployment
85
Configuring Floppy Maker
The technology behind Floppy Maker
Brainware OS Deploy boot diskettes use a standardized structure, which offers the
following functions:
An option to boot the machine (by default a US MS-DOS 6.22 is supplied; other DOS
systems can be made available on request).
Creating a RAM drive and its configuration
Analyzing and partitioning the hard drives
Various keyboard layouts
Executing additional batch files prior to the setup
Starting Windows Setup
All modules are contained in a simple directory structure (..\FpyMaker). You can therefore
add your own extensions.
The directory structure
Floppy Maker uses a special directory structure to store the different configurations.
Abbildung 63: Floppy Maker - Directory Structure
Description of the directories
Directory
FpyMaker
86
Columbus OSDeploy
Description
The main directory of the application; it contains
floppymaker.exe. This directory can be renamed as
desired and can be copied to other locations. All diskette
images (*.fpy) are stored in this directory.
Connect
This directory contains the various 'connectors' needed
in Floppy Maker. This directory must always be available
and may not be renamed.
The directory contains subdirectories such as CD-ROM,
Microsoft IP and NetBEUI, Novell IPX, Novell VLM,
Parallel Port Devices.
CD-ROM
A subdirectory that contains the drivers necessary for
supporting CD-ROM under DOS. This directory contains
additional subdirectories with the name of the CD-ROM
drive.
General files that are identical for all drivers are filed in
the subdirectory BASE.
Microsoft IP and
NetBEUI
The subdirectory that contains the drivers necessary for
Microsoft IP or NetBEUI protocol under DOS.
This directory contains subdirectories with the name of
the network card.
General files that are identical for all drives are filed in
the subdirectory BASE.
Keyboard
This directory contains the different types of keyboard
layouts. This directory must always be available and
may not be renamed.
This directory contains subdirectories in which various
keyboard layouts are stored, e.g. French, German, Swiss
German, United States,...
Params
Different parameters such as Servername, IP address,
etc. are stored here. This directory may not be deleted or
renamed.
The different parameters can be found in the params.txt
file, in designated subdirectories.
Partition
This directory contains the various partitioning
schemas; it may not be deleted or renamed.
Subdirectories should be labeled with names such as
'6GB system partition and rest partition'.
General files that are identical for all drives are filed in
the subdirectory BASE.
Modifications to the boot diskette
Settings that can be performed on the boot diskette are stored in the directory structure
described earlier. The actual modification options are explained here.
Chapter 4 Getting to grips with OS deployment
87
The parameter file
OS Deploy uses text files to determine the configurations. If you add a new site or config in
the release, you must update and adapt the settings in the Floppy Maker directory. This
applies to Floppy Maker in the file ..\Support\FpyMaker\Params\<Description>\params.txt.
params.txt
Description
_ASetupSrv=MyServer
The name of the servers on which the OS Deploy
source can be found.
_ASetupShare=Columbus
The name of the release on the server mentioned
above that the OS Deploy source makes available.
It is recommended that you use a hidden release
with 8.3 notation, as the release should be
accessed from DOS. After the standard installation
this release is known as Columbus.
_SourceDrv=M:
The release is incorporated in these drive letters.
_SourceDir=M:\OSDepot
This entry indicates the directory in which the
release source (asetup.bat) can be found (including
drive letters).
_ASetupAcc=MyAccount
The user account that has the rights to read the
source directory, write to the profile directory and
add computers to the domain.
_ASetupAccPW=MyPassword
The password of the user account mentioned
above.
_ASetupDomain=MyDomain
The domain in which the user account mentioned
above is a member.
_MP=1500
The minimum size of the system partition in MB.
Recommendations: NT4 - 350MB, Win2000 2000MB, WinXP - 2000MB.
Network-specific parameters
The following parameters are not required when a standalone installation is
performed.
_MSPROTOCOL=T
'T' indicates TCP/IP, 'B' indicates NetBEUI.
_DHCP=yes
If DHCP is not available, set this parameter to 'no'
and set up an IP configuration as indicated below.
_IPAddr= 10 20 30 40
If the parameter _IPAddr is defined, a selection
dialog for the IP address is not displayed. By using
_IPAddr1, _IPAddr2, etc. you can restrict the
selection to specific subnets.
_IPAddr1=10
_IPAddr2=20
_IPAddr3=30
_IPAddr4=40
88
Columbus OSDeploy
_IPSubnet=255 255 255 0
_IPSubnet1=255
_IPSubnet2=255
If the parameter _IPSubnet is defined, it cannot be
changed in the menu. This parameter is the same
as _IPAddr in other respects.
_IPSubnet3=255
_IPSubnet4=0
_IPGate=10.20.30.250
_IPGate1=10
_IPGate2=20
If the parameter _IPGate is defined, the gateway
cannot be selected. This parameter is the same as
_IPAddr in other respects.
_IPGate3=30
_IPGate4=250
General parameters
_LANG=EN
'EN' (English) and 'GE' (German) are supported. This
determines the language of the boot diskette.
_Yes=Y
The 'JA' parameter for answers in DOS. 'Y' for
English DOS or 'J' for German DOS (This parameter
is dependant on the DOS version used and not on
the language selected above.)
_Disk=6_0
The version of the boot diskette. The version must
correspond to the disk6_0.flg file stored in the
release (directory setup). If this is not the case, the
setup is terminated.
_SysDrv=C:
The drive on which Windows is installed.
_FmtC=T
This parameter must be set to 'T' if the C: drive is to
be formatted during the setup, and to 'F' if it is not
to be formatted.
_FmtD=F
This parameter must be set to 'T' if the D: drive is to
be formatted during the setup, and to 'F' if it is not
to be formatted.
_AUTO=
Set this parameter to 'T' if you want OS Deploy to
operate in fully automatic mode. Not even the
intro screen is not displayed (recommended for
experienced users only).
_MAINT=Y
Set this parameter to 'Y' if the OS Deploy release
contains an extended menu for disk images or
tools such as PartitionMagic (..OSDepot\service)
_Mode=/3
If this parameter is set to '/S', Windows 3.11 starts
the 'Profiler' in Standard mode. If the parameter is
not set or is set to '/3', Extended mode is used.
Some machines, and Win98 for example, do not
support the Extended mode of Windows 3.11.
Chapter 4 Getting to grips with OS deployment
89
_CDONLY=
This parameter must be set to 'T' if the OS Deploy
source is on the same CD-ROM from which it was
started.
The _SourceDrv and _SourceDir parameters must
point to the drive letters used by the CD-ROM
drivers.
_RequestName=
Set this parameter to 'T' if the name of the person
performing the staging is to be requested and
written as feedback.
_MemorySaver=
Set this parameter to 'Y' to save DOS memory.
Some modules (e.g. keyboard) are then not loaded,
in order to prevent memory problems.
_UDPPort=
Set this parameter to the port number (normally
9880) via which the status of the installation is
transmitted to the console.
_TabletPC=
Set this parameter to 'T' if the computer is to be
staged as a Tablet PC with Microsoft Windows XP
Tablet PC Edition.
Setting the following parameters allows pre-selection of the release, the site and the
config, to enable the process to be further automated. If the parameters are set, the
selection of the release is not displayed and the corresponding profile is started.
_Release=RELEASE.MY
_Site=SITE.MY
_Config=GENERIC
90
Columbus OSDeploy
Adding connectors
Many connectors are delivered with Floppy Maker, although the exact ones required for
your network card may not be included. In this case you need to add the relevant connector
yourself.
One of the biggest advantages of the OS Deploy boot diskette is its modular structure,
which allows different connections to be set up with one diskette image.
Classification of connectors
All classes of connectors are defined in the directory ..\FpyMaker\Connect\. You can add
additional classes by creating a directory.
The \BASE directory
Every class has a matrix of drivers and batch files. The connect.bat file is (must) be used by
all drivers in a class. This matrix of files is stored in the subdirectory \Base. An example of
connect.bat for a CD-ROM drive is
rem ====== CD-ROM drivers =======================================================
@echo off
echo CD-ROM drivers
%RD%\mscdex.exe /D:LOCCD /M:15 /L:L
rem switch site-specific parameters to local CD, if not set correctly in
params.txt
if exist %_SourceDir%\asetup.bat goto END
set _ASetupSrv=
set _ASetupShare=
set _SourceDrv=L:
if exist %_SourceDrv%\Asetup\asetup.bat set _SourceDir=%_SourceDrv%\Asetup
if exist %_SourceDrv%\asetup.bat set _SourceDir=%_SourceDrv%
:END
The file for a CD-ROM is fairly simple. By looking at a connect.bat file for the IP/NetBEUI
environment, you will notice that these can be fairly complex, depending on your
requirements.
For example, for the integration of a network adapter for an IP connection into the boot
diskette, it should be sufficient in most cases to copy the driver files (*.DOS) and to enter the
name of the driver.
Driver selection
In turn, a list of drivers that can be selected exists within a connector class, e.g. for different
network cards. The content of these directories can vary, depending on what was specified
in the \BASE directory.
For example, for a network driver that will load TCP/IP, you need a params.txt file
containing the name of the card driver.
_MSNETDRV=EL90X
The driver files for this network card must then be in the corresponding directory
(..\<Name>\connect\msnetdrv).
Chapter 4 Getting to grips with OS deployment
91
Microsoft IP and NetBEUI
Create a directory with the name of the card in the directory
..\FpyMaker\CONNECT\Microsoft IP and NetBEUI. This directory then appears in the
connectors selection in Floppy Maker.
We recommend that you copy an existing directory and swap the corresponding files.
Everything that you copy to this directory is copied to the Connect directory on the boot
diskette.
The Connect directory must exist in the directory that you created.
Use a file editor to create or modify the params.txt file .
Add a line with the following entry:
_MSNETDRV=[file name of the driver without extension]
Example:
_MSNETDRV=EL59X ;COMMENT Name of the network driver to be loaded
Create the MSNETDRV in the Connect directory (if it does not already exist), and copy the
driver files across.
If your network card requires additional files, you can simply add these; e.g. if the card
requires a special config.sys file, copy the amended config.sys file to the directory that you
have created for this card (..\FpyMaker\CONNECT\Microsoft IP and NetBEUI\<Name der
Karte>). This is required, for example, for some Token Ring or PCMCIA network cards.
92
Columbus OSDeploy
Changing the Microsoft client
This information is based on Microsoft Knowledge Base articles.
The OS Deploy boot diskette contains a pre-configured Microsoft Network client.
If you want to change the client for one boot diskette only, please do this in the directory
A:\Connect. If you want to change the client for all boot diskettes, change the client in the
msnet.zip file in the directory ..\FpyMaker\CONNECT\Microsoft IP and NETBEUI\Base
Modifying the startup disk for NWLink frame types
Extract the file protocol.ini from the msnet.zip file and open it using Notepad or a text
editor. Look for the protocol section of the file; it is preceded by a header, which appears as
follows:
[ms$nwlink]
Below the title, find the value that appears as follows:
FRAME=Ethernet_802.2
This is the default setting. Change 'Ethernet_802.2' to the appropriate frame type for your
network. The frame types available must be entered exactly as they appear here. The
choices are as follows:
Ethernet_802.2
Ethernet_802.3
Ethernet_II
Ethernet_SNAP
TOKENRING
Save the changes in the file and update the file msnet.zip with the new version. You can
also add this modified protocol.ini file to the \MSNETDRV sub folder. During the staging
process it will be copied to the Net folder together with the driver file and will overwrite the
protocol.ini file provided with the msnet.zip file.
Additional TCP/IP settings for the Microsoft Network client for
MS-DOS
Specifying WINS servers
If your Microsoft Network client for MS-DOS uses DHCP (the default setting for MS-DOS
TCP/IP), it will automatically receive the address for the Windows Internet Naming Service
(WINS) server. If you want to statically configure your WINS server IP address, you must edit
the client's protocol.ini file and add the IP address to the [TCPIP] section.
For example, if you have two WINS servers available, add them to the [TCPIP] section as
shown in the example below. Note that there are no dots (.) in the IP addresses.
[TCPIP]
WINS_SERVER0 = 11 101 13 53
WINS_SERVER1 = 11 101 12 198
Chapter 4 Getting to grips with OS deployment
93
Name queries will be sent to the WINS servers in the order in which they appear in the .ini
file. The ipconfig command may show a different order of WINS servers (or even different
WINS servers altogether) - these are the WINS server names sent by DHCP, and the
protocol.ini settings override them.
Important: There is a difference in functionality available in TCP/IP for Microsoft®
Windows® for Workgroups, Windows NT Workstation, and Windows NT server, as
compared to MS-DOS TCP/IP. Specifically, an MS-DOS TCP/IP client does not:
Support DNS resolution using WINS.
Support WINS resolution using DNS.
Register its name with the WINS database - it performs queries only.
Logging on with TCP/IP across a router
If the domain controller is across a router from the Microsoft Network client for MS-DOS
computer, you must add a line to the client's LMHOSTS file (located in the msnet.zip file. If
there is no LMHOSTS file, you need to create one) for logons to be validated. The line has the
following format:
www.xxx.yyy.zzz SRV_Name #DOM:DOM_Name
where:
www.xxx.yyy.zzz is the IP address of the domain controller.
SRV_Name is the NetBIOS name of the domain controller.
DOM_Name is the name of the domain.
You must also ensure that the domain controller can contact the Microsoft Network client
for MS-DOS using one of the following methods:
Enter the client's IP address and name in the domain controller's LMHOSTS file.
Register the client with a WINS server that is accessible by the domain controller
(placing a static entry in WINS for the Microsoft Network client for MS-DOS).
ipconfig.exe and controlling DHCP leases
The ipconfig.exe utility provides DHCP configuration information only. The version of
ipconfig.exe provided with the Microsoft Network client for MS-DOS does not support
command-line switches for controlling DHCP address leases. You must use the DHCP
administration utility instead.
Save the changes and update the file msnet.zip with the new version. You also can add this
modified LMHOSTS file to the \MSNETDRV sub folder. During the staging process it will be
copied to the Net folder together with the driver file and will overwrite the LMHOSTS file
provided with the msnet.zip file.
Adding Network Interface Cards to Microsoft standard startup
disks
Modifying the startup disk for Network Interface Cards (NIC) that are not provided with the
Microsoft delivery requires the installation of the appropriate MS-DOS driver and the
editing of two system files.
94
Columbus OSDeploy
Install an NDIS2-compatible MS-DOS driver for the NIC. These are usually provided with
their drivers on the boot disk supplied by the manufacturer. If no drivers are available,
download the appropriate driver from the manufacturer's web site.
Appropriate drivers for the Microsoft Network client for MS-DOS will always have a .dos
extension. For example, the driver for Intel's EtherExpress Pro/10 EISA is:
Epro.dos
This driver should be placed in the Net directory on the computer (C:\Net, unless named
differently) or on the MS-DOS startup disk (A:\Net).
Modifying the system.ini file. The NIC driver needs to be referenced in the system.ini file.
This entry is found in the [network drivers] section, as illustrated below:
[network drivers]
netcard=elnkii.dos
transport=ndishlp.sys,*netbeui
devdir=A:\NET
LoadRMDrivers=yes
For 'netcard=,' replace the current driver with the file name of the NDIS2-compatible driver
placed in the Net directory (for example, Epro.dos).
Modifying the protocol.ini file. The NIC driver needs to be referenced in the protocol.ini file.
This entry is found in the [ms$ driver_Name] section (the driver name will reflect what was
originally chosen in the network installation startup disk process), as shown below:
[ms$elnkii]
drivername=ELNKII$
; INTERRUPT=3
; IOADDRESS=0x300
; DMACHANNEL=1
; MAXTRANSMITS=12
For 'drivername=,' replace the driver listed with the file name of the NDIS2-compatible
driver. Use a dollar sign ($) to replace the .dos file extension (for example, EPRO$).
Using OS Deploy...
It is much easier to make all these changes using OS Deploy As described above, copy the
MS-DOS driver file to the directory ..\Connect\MSNetDrv on the diskette and edit or create
the params.txt file in the Connect directory using an editor.
Add the following line to the file, or edit it appropriately to indicate the name of your MSDOS driver.
_MSNETDRV=Epro
All other changes to protocol.ini and system.ini that are required are automatically
performed on the boot diskette by connect.bat.
References
The following articles in the Microsoft Knowledge Base provide additional information on
this topic.
Q135465 - README.TXT: Microsoft Network client version 3.0
Q128800 - How to Provide Additional NDIS2 Drivers for Network client 3.0[winnt]
Q142857 - How to Create a Network Installation Boot Disk
Chapter 4 Getting to grips with OS deployment
95
Q130875 - Troubleshooting MS Network client 3.0 and DHCP
Q128751 - No "Advanced" button in client TCP/IP Configuration Box
Q123285 - IPCONFIG Displays Invalid Results
Q130538 - DHCP-Enabled MS-DOS Clients Do Not Resolve Host Names
Adding keyboard layouts
Floppy Maker offers you a selection of keyboard drivers/settings that can be used during
the DOS part of the setup. Please read the following information if you require a keyboard
layout that has not been supplied by us or if you want to limit the number of layouts on
offer.
All keyboard layouts available in Floppy Maker are subdirectories of the \Keyboard directory.
Additional options can be added by adding a subdirectory with the corresponding name. A
file with the name keyboard.bat must be stored in this directory. This file loads the
appropriate keyboard.
Structure of keyboard.bat
This keyboard.bat file is called via autoexec.bat on the boot diskette.
rem ====== Keyboard =========================================
@echo off
echo US layout
loadhigh %LD%\Dos\keyb us,850,%LD%\Dos\keyboard.sys>nul
The above code is an example of what the contents of a batch file should look like. Please
consult a DOS manual to find out how to load the keyboard driver you selected.
96
Columbus OSDeploy
Changing the intro screen
Replacing the intro screen
It is recommended that you do not edit the intro.bat file (A:\Module), as this file could be
updated in a subsequent version of the boot diskette. This would mean that you would
have to re-enter all your changes. You can, however, execute your own file before the
intro.bat file.
Create a file namedoemintro.bat in the \Module directory of the boot diskette. This batch file
is then executed before intro.bat. If you execute the
set _OEMINTRO=T
command in your oemintro.bat file, intro.bat will no longer be executed. If the variable has
a value other than 'T', intro.bat is executed directly after oemintro.bat.
Switching off the intro screen
The intro screen was set up to make it easier for new users to become familiar with the
process. As soon as you have become familiar with the product and you feel that the intro
screen bothers you, add the line _OEMINTRO=T to your params.txt file, or delete the file
..\module\intro.bat from the generated boot diskette.
Modifying the menu
The text displayed in the intro screen is activated by simple echo commands in intro.bat. It
is a simple task to change this text.
Copy the intro.bat file into the oemintro.bat file; in this way the original file remains
unchanged. Add the command set _OEMINTRO=T. Then modify the file as you wish. We
recommend that you leave the number of lines unchanged to ensure that the readability of
the display is preserved. Use 'echo' to send a blank line. Ensure that there is an English and a
German text.
Converting an emergency diskette back to a normal boot diskette
You have the option of converting a boot diskette back to an emergency diskette during the
setup of a machine. Using this diskette you can restore the relevant computer without
keystroke entries. In this way, an end user can, for example, recover his/her machine at a
remote location without the help of an administrator.
If you want to convert the diskette back to a 'normal' diskette that can be used for multiple
machines, all you need to do is delete all files with the name 'FIRSTAID.*' in the ..\module
directory.
Chapter 4 Getting to grips with OS deployment
97
Changing the boot diskette
The installation process is clearly divided between the boot disk functionality and the
execution of the Windows Setup process by means of batch files in the OS Deploy release.
If you want to develop your own boot diskettes or boot procedure, you must ensure that the
following variables are set before the asetup.bat file is called by the OS Deploy release.
TEMP
Indicates the directory to which the temporary files can be
copied.
_SOURCEDRV
The variable for the drive on which the setup source can be
found.
_SOURCEDIR
The variable for the drive and path on which the setup source
can be found.
_FMTC
The variable indicating whether the C: drive should be
formatted (T) or not (F).
Master boot diskette
Brainware supplies an image of a boot diskette with OS Deploy. In this way, you can use the
functionality of OS Deploy even without PXE.
This image is normally called '_Master DOS Bootdisk vXXX.fpy', where XXX describes the
version of the image, e.g. 650. This is stored in the FloppyMaker directory and can normally
be found under ...\OSDepot\Support\FpyMaker.
For licensing reasons, the supplied image is MS-DOS 6.22. Under PXE, from Columbus 6.5 a
Windows 98 boot diskette is used. This is not yet suitable for staging with boot diskettes,
due to the Workstation Profiler.
Structure of the boot diskette
If you create a boot diskette with the supplied image, you will find the following files and
directories on the diskette.
Directory / file
Description
This file is needed for booting the computer.
io.sys
This file is needed for booting the computer.
msdos.sys
command.com
config.sys
98
Columbus OSDeploy
This file is needed for booting the computer.
The config.sys is prepared for loading network drivers. CDROM connectors (if selected when generating the diskette)
replace this file for loading CD-ROM drivers.
autoexec.bat
DOS
The autoexec.bat file controls the entire 'staging' process and
should not be changed.
This directory contains the necessary DOS 6.22 files.
Module
This directory contains the -necessary OS Deploy-specific files
and configuration files.
Connect
The corresponding drivers and configurations for connecting
to the OS Deploy release are stored here.
Part
Tools
This directory contains the partitioning schema selected.
This directory contains additional tools needed to guarantee
functionality.
Migration of AutoSetup environmments
Columbus OSDeployment brings a lot of new features and enhancements compared with
AutoSetup. But we tried to keep the structures as compatible as possible in order to ensure
a migration of existing AutoSetup releases.
Important differences
AutoSetup
OSDeployment
Folders
ASetup
OSDepot with new batch files and tools
ASetup folder shared as ASetup$
Columbus Data folder shared as Columbus$.
Beneath is OSDepot
Images
Computer.img and in every release a seperate
folder Image
New batch and input files. Diskimaging support
in the console over PXE
Tools
Service, which is used for the PXE Service Boot.
no naming conventions for
release folders
Setup installs and maintains the release folders
WinXP, Win2000, Win2000.Srv and
Win2003.srv. You may manually rename those
folders.
Chapter 4 Getting to grips with OS deployment
99
Jobs
site specific jobs underneath the
site folder
Sitespecific jobs are not supported in the
console. All jobs must reside in the job folder
underneath the release.
Config files
Choices.ini
added partitioning schemas, other entries are
compatibel.
Options.ini
new section [Database] with the database
connection parameters, other entries are
compatibel.
For preselection of certain options in the
configuration dialog in the console, there are
new entries under the section [Defaults], this is
optional.
Operations
Boot diskette
PXE
workstation profiler (profiler.exe) Columbus Console (CMC.exe), computer
windows, tabs OS
By default individual ASetup
account
By default a Columbus account for SW and OS
deployment
Changes and new jobs available
immediately
Every modification requires an update to the
database via a List Refresh in the OS
Deployment agent
100
Columbus OSDeploy
How to migrate?
The following steps are tips from a real world scenarioand should guide you through the
process of a migration.
Setup of a new OSDepot
Install a new OSDepot release for the appropriate operating system.
Transfer the i386 folder from your existing release. Take the chance and integrate the
current ServicePack into your windows sources (slipstream).
Remove unused jobs from the release.
Remove not needed or not wanted options from choices.ini.
Delete connectors and partitioning schemas from FloppyMaker.
Test your release, if everything is working.
Transfer your old adaptations
Copy over your own Jobs. USe this opportunity to clean up and check if you really still
need those jobs
Copy your existing sites into the new structure
Jobs beneath a site have to be moved to the job folder in the root of the release folder,
if you plan to use PXE.
Add the new entries to your existing configuration files Choices.ini and Options.ini.
If you haven't modified those files a lot, we recommend to continue to use the new
configuration files and customize them.
Existing profiles können für das Aufsetzen mit Bootdisketten grundsätzlich wieder
verwendet werden. You have to add the sektion Database to all the Options.ini files,
wich are named after the workstation ID in the profile folder (for instance S01.ini). This
also takes place, when you open a computer profile in the workstation Profiler and save
the configuration again.
Do not transfer
Batch files and tools from the ASetup folder
the ASETUP job
the master boot disk from FloppyMaker
Chapter 4 Getting to grips with OS deployment 101
Configuring infrastructure services
The Columbus infrastructure server has an agent that administers the OS Depot required
for the OS deployment. The OS Deployment agent reads the configuration settings and jobs
for the available operating system releases into the database. Only then can computers be
configured for an OS deployment. For this, the agent needs to know the location of the OS
Depot and with which users from the computers to be set up it can access the Depot.
Setup provides the default settings to the agents once only. This can be changed at any
time, however. A reconfiguration is particularly necessary if you want to change the user or
the OS Depot server.
If you add further infrastructure servers that are also to offer OS Deployment services, these
must be configured manually in the database, as the setup can only execute the initial
configuration in an empty database. You might need additional infrastructure servers
particularly at external locations where computers are to be set up and you do not want to
overload the network connections between the locations.
The infrastructure services can be configured as follows
Switch to the Infrastructure view in the console. All services registered in the current Columbus
database can be seen in the overview table. The column Computer contains the name of the
appropriate Infrastructure server. Different services are available on every server. The
column Service contains the designation of the current service.
To edit this, choose the desired service from the appropriate server by selecting the
corresponding line.
102
Columbus OSDeploy
OS deployment
The OS Deployment service is responsible for linking and managing the Operating System
Source Depot.
Carry out the following steps:
Abbildung 64: OS deployment
Assign to company
See Assign service to company (assign to company)
Configure
The path to the Operating System Source Depot is a central source of information for the
OS Deployment server. To enter configuration information, highlight the OS Deployment
service and select the Configure task pane function. The Add OS Source wizard is started.
Abbildung 65: Add OS Source wizard
You now have the option of specifying a network drive as the Operating System Source
Depot. Enter the UNC path of the network drive, as well as the necessary user information
for an external connection to the sources.
Chapter 4 Getting to grips with OS deployment 103
Abbildung 66: Specifying an OS Depot
Source
directory that contains the OS sources. Use only UNC
notation (\\servername\release\directory1\directory2).
The path may be entered manually or it can be found via
the Browse button.
Where OS sources to be linked are stored on an external file server, user information
necessary for network access must also be recorded. If the OS sources can be found on the
same server where the OS Deployment service is running, the fields in question may be left
blank.
Domain
Domain name
User
User name
Password
Password of the user entered
Abbildung 67: The Add OS Source wizard is complete
104
Columbus OSDeploy
Schedule
The list must be refreshed manually or in regular intervals if changes to the OS source list
are to be propagated in the Columbus system. To do this, start the Schedule List Refresh task
pane functionvia the OS Deployment Index wizard.
Abbildung 68: OS Deployment Index wizard
Enter the start date and time of the first list refresh in the template shown below. If
required, select the repeat interval for regular refresh.
Abbildung 69: Refreshing the OS source list
Date
Date of first refresh (format: dd/mm/yyyy).
Time
Start time of first refresh{(format hh:mm:ss).
Chapter 4 Getting to grips with OS deployment 105
Job is executed repeatedly If this box is checked, the list is repeatedly refreshed at the
intervals specified. In all other cases a refresh is only
performed once.
Repeating interval is ....
minutes
Interval in minutes for repetitive refresh.
The planned refresh is confirmed by the wizard after successful configuration. In addition,
the planned action is listed in the Infrastructure view in the Scheduled Actions tab.
Abbildung 70: Liste der geplanten Aktionen (Actions)
Activate
See Activate service
Drag & drop to company tree
See Functional responsibility (drag & drop)
106
Columbus OSDeploy
Preboot services
The Preboot services agent is responsible for dealing with all PXE requests.
Carry out the following steps:
Abbildung 71: Preboot services
Assign to company
See Assign service to company (assign to company)
Activate
See Activate service
Pre-Boot Execution Environment (PXE)
Abbreviation for P re-boot E xecution Enviroment. PXE is one of the components of WFM
(Wired for Management), as specified by Intel. It allows a computer to connect to a server in
a network before the actual operating system has been started from the local hard drive.
Using PXE, a machine is connected to the network even if it is not switched on.
Chapter 4 Getting to grips with OS deployment 107
WakeOnLan
'WakeOnLan' (WoL) must be available on the computers to be able to achieve full PXE
functionality. This allows a machine to be switched on remotely, as long as one knows the
MAC address of the built-in network card. With WoL, it is no longer necessary for an
administrator to switch on the machine locally. At the same time, one can load diagnostic
programs by means of PXE, for example, or in the case of OS Deploy an inventory program
for the preparation of an unattended setup on the computer.
In the infrastructure, the Columbus Base Agent must be assigned to the site for WOL to
work.
The console passes the WOL action over to the local infrastructure server of the site, where
the computer is placed. There the Base Agents sends out the broadcast to the computer.
This is a unique feature of Columbus and allows to wake up computer in different subnets,
even over routers in different locations!
WoL is based on a Magic Packet broadcast that is sent on the network. To ensure that WoL
operates successfully, you first need to get the assurance of the network team that the
broadcast will not be filtered. Furthermore, you need to check that the PC accepts
WakeOnLan. Not every network card that appears to be able to accept WoL does in fact
accept it. A BIOS upgrade often helps to resolve this issue.
PXE images
A TFPT server (Trivial File Transfer Protocol) is used as part of PXE; this makes images
available for computers. These images are copies of normal boot diskettes that are then
executed on the computer as a type of 'virtual' diskette drive.
The following diskette images are available in OS Deploy.
This image can be used to partition the hard drive of a computer.
configure.bin
netsetup.bin
This image can be used to trigger the installation of the operating
system.
service.bin
This image can be used to create access to the OS Deploy server to make
tools available for support personnel.
unknown.bin
108
Columbus OSDeploy
This image is responsible for the recording of computers that have not
yet been recorded in the console. Hardware recognition is also performed
here.
PXE and OS Deploy
This staging example explains the use of PXE in OS Deploy.
The prerequisite for this example is a ready configured OS Deploy server and a newly
delivered, empty computer.
1
Inventory (unknown.bin)
When a computer is started for the first time in the network, it requests a so-called
inventory image from the TFTP server (that is installed on the OS Deploy machine) and
executes this image. This inventory image reads the hardware information of the
computer and transmits it to the database of the OS Deploy servers. The computer is
then automatically switched off again. The computer is then added to the console by
means of its MAC address, and can be renamed and staged from here.
2
Preparation of the computer(configure.bin)
After the computer has been assigned a configuration in the console, it is switched on
remotely by WoL. The computer requests the appropriate image via the network and
executes it. In this case, this is the partitioning of the hard drive. The machine is then
restarted.
3
Installing the operating system (netsetup.bin)
After the hard drive has been prepared, the actual installation of the operating system
can begin. After the second restart, an image is again requested from the server. On this
occasion, the installation of the operating system is triggered.
In this way, an operating system can be installed on a computer without any local activity
by an administrator. The recording of the machine in the database can either occur
manually, by means of a bar code scan at delivery time or by the local technician switching
on the device after setup.
Chapter 4 Getting to grips with OS deployment 109
CHAPTER 5
Columbus PXE filtering
More and more suppliers are offering network functions based on PXE services. PXE
architecture is based purely on UDP broadcasting, and as such is not able to control which
client is served by which PXE server. As a result, the installation of multiple PXE servers by
different suppliers in the same subnet leads to the servers taking away client requests from
one another.
The purpose of Columbus Preboot Services to avoid this irrecoverable design error in the
PXE specification, in two phases:
1
Introduction of a filter file that allows the Columbus PXE server to decide which client
requests to respond to and which ones to ignore.
2
Active receipt of all PXE requests in a subnet, whereby all services that are not
performed by Columbus are forwarded to the responsible PXE server.
Phase 1 will be released in Columbus 6.7; phase 2 is still being developed.
In this chapter
What is the potential of PXE filtering............................................ 111
The PXE filter file................................................................................... 112
Evaluating the filter file...................................................................... 113
What is the potential of PXE filtering
By entering the MAC addresses, the computers to which a PXE server must respond can be
specified. In this manner, it is possible to operate multiple Columbus PXE servers on one
subnet. For example, test computers can be assigned to a specific PXE server, or a different
PXE server can be assigned to a Terminal Server farm instead of the desktops in a company.
This ensures that Columbus does not grab PXE requests from another system, but rather
remains inactive. However, this does not prevent different PXE servers, which do not
support filtering, from answering the requests from Columbus stations.
In addition to the MAC address limitation, it is possible to define time frames during which
the PXE functionality should be available. By setting time frames, it is possible to limit the
functionality during the morning load, thereby counteracting the inevitable need of having
to extend the PXE infrastructure.
The introduction of phase 2 in 2006 will massively extend the function, allowing for load
balancing, failover etc., in addition to being able to control all PXE traffic. More information
regarding this at a later stage.
111
The PXE filter file
PXE filtering is based on a filter file that contains definitions as to which clients should
receive responses. In principle and in structure, it can best be compared to a HOSTS file.
For PXE filtering to be active, the file PXERules.txt must be contained in the application
directory of the PXE server together with the appropriate entries. This is generally the
Columbus\Infrastructure directory on the corresponding Columbus Infrastructure Server.
%ProgramFiles%\Columbus\Infrastructure view in the CMC\PXERules.txt
Filter file setup
This file is purely a text file, which can be edited with any text editor. The following
commands are available:
Command
Description
ExcludeDevice
This command defines which MAC addresses NOT to respond to.
Either the entire MAC address can be specified or a placeholder (*)
can be used. The "*" may only be used at the end of a MAC address
in each case, or as a placeholder for all addresses.
Example: ExcludeDevice, 000423523710
IncludeDevice
This command defines which MAC addresses to respond to. The
entire MAC address can be specified, or a "*" placeholder may be
used. The "*" may only be used at the end of a MAC address in each
case, or as a placeholder for all addresses.
Example: IncludeDevice, 0004*
ExcludeTime
This command defines the times during which the PXE server must
not serve a client. As this is a "reduction of service" setting and not
an exclusion, the client also receives a reply during this type of time
frame. However, this reply only states that no action is required without the PXE server ever having checked with the Columbus
database. As a result, it merely ensures that OS deployment cannot
start on the client at 8:00, for example.
Example: ExcludeTime, 06:00-10:00
;
Rows beginning with a semicolon ; are comment rows.
; This is a remark
112
Columbus OSDeploy
Example File PXERules.txt:
; Managed Preboot sample script
; Exclude all MAC addresses (answer to none)
ExcludeDevice, *
; Exclude specified MAC addresses (answer to none)
ExcludeDevice, 000423523710
ExcludeDevice, 000423523710
; Exclude specified group of MAC addresses
ExcludeDevice, 000423*
; include all MAC addresses (answer to all)
; This is the default, if nothing is specified
IncludeDevice, *
; include specified MAC addresses
IncludeDevice, 000423523710
; include specified group of MAC addresses
IncludeDevice, 0004*
; Define time window to exclude
ExcludeTime, 0600-1000
Evaluating the filter file
The filter file is evaluated according to the sequence of the entries. The basic setting is that
all requests are answered.
If you want to process certain MAC addresses only, all MAC addresses must first be
excluded. Then add all the permitted addresses again in rows:
ExcludeDevice, *
IncludeDevice, 000423*
Troubleshooting OS deployment
In practice, most problems are caused by PXE functionality. Unfortunately, the stability of
PXE is extremely dependent on the implementation of this functionality in the network
cards, switches and routers. Devices that are newer than 1998 (the year in which PXE was
normalized) should in fact be able to support this standard. However, in reality the picture
is not that good. Faulty BIOS versions are common, as are cheap components that do not
even support PXE.
If problems occur when booting PXE, such as Access Denied messages, emm386 errors or
other unusual errors, we recommend that you proceed as follows:
1
Update the BIOS to the very latest version
2
Check the policy entries in Windows 2003 servers
3
Usage of an LMHOSTS file
4
Usage of a native NDIS driver
5
Trace the network components responsible for the error.
Chapter 5 Getting to grips with OS deployment 113
BIOS update
If you activate PXE in the computers' BIOS or tailor the boot sequence for PXE, we
recommend that you also perform a BIOS update to the latest level as a matter of urgency.
In this way, numerous instabilities and unusual errors that are not easily explained can be
avoided.
Note that even new computers from well-known brand names are often supplied with
completely out of date BIOS versions.
Follow the computer manufacturer's specifications for updating the BIOS. New versions can
generally be downloaded from the suppliers' web sites.
Check the policy entries in Windows 2003 servers
When using a Windows 2003 Server, Microsoft issues a system message indicating that
access by DOS clients to the server is no longer supported by default. But who bothers to
read this?
To turn on support for DOS clients again, you need to modify the following policy entries.
All entries with signing and always must be inactive, and
send NT& NTLM responses must be allowed.
If Columbus is installed on a domain controller, these entries must be set in the separate
domain controller policy, as this overrides group and local policy. You can execute
gpedit.msc to tailor local policies.
In the appropriate Policy editor, change to
\computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options
Ensure that the following entries have been set
Domain member: Digitally encrypt or sign secure channel data (always)
Disabled
Microsoft Network client: Digitally sign communications (always)
Disabled
Microsoft network server: Digitally sign communications (always)
Disabled
Network security: LAN manager authentication level
Send LM & NTLM - use NTLMv2 session security if negotiated
114
Columbus OSDeploy
or even weaker: Network security: LAN manager authentication level
Send LM & NTLM responses
Allow remote administration functions
On Windows XP workstations the sharing model must be set to classic so that remote
administration functions such as client rollout, real time monitor etc. can be used.
Network access: Sharing and security model for local accounts
Classic - local users authenticate as themselves
You can achieve the same effect by changing the following settings in Windows Explorer:
Select the menu:
Tools\Folder Options\View
Deactivate the option:
Use simple files sharing (recommended)
Chapter 5 Getting to grips with OS deployment 115
LMHOSTS file
In modern networks, name resolution occurs exclusively via DNS. Consequently it is possible
that the client is unable to find the Columbus OS Deploy server or the domain controller in
the network. If access is denied, the client has found the OS Deploy server, but no domain
controller that can execute user authentication. In this case it is useful to add the domain
controller and the OS Deploy server to the LMHOSTS file.
When the native NDIS driver is not used, you can find the standard LMHOSTS file in the
directory ..\Columbus\Infrastructure\PXETemplates\netsetup.bin.net\
The entries must occur as described below.
[IP-address] [Netbiosname of the domaincontroller] [#DOM:Domainname]
[IP-address] [Netbiosname of the Columbus server]
Example:
#
#
#
#
#
This is a sample LMHOSTS file used by Microsoft TCP/IP
For example:
149.124.10.2 dc #DOM:mydomain #PRE
149.124.10.4 server1
# main office server
10.0.0.1
MYDC
10.0.0.2 MYDBSERVER
10.0.0.3 MYCISSERVER
116
Columbus OSDeploy
#DOM:MYDOM
Native NDIS driver and PXE
Due to incompatibilities between network cards (e.g. Broadcom, 3COM, Intel), System Bios
and PXE, the staging by means of PXE can sometimes fail to function. After the image has
been loaded and the computer is to connect to the release to perform the setup, a 'hang'
condition can occur without a message being displayed, or the following message can be
displayed: "EMM386 has detected error #12".
From version 6.4 of Columbus, it is possible to use the native NDIS driver for the network
card instead of the generic UNDI driver.
To activate this functionality, create the following entry in the registry for the Columbus OS
Deploy server.
Key: HKLM\SOFTWARE\Brainware\Columbus\6\OS Management\StagingParams
String:NativeNDISDrivers=1
After the next restart of a client with PXE, the OS Deploy agent creates a directory in the
directory ..\Columbus\Infrastructure\PXETemplates based on the name of the network
card. If it is not possible to determine the name of the card, the 6 characters (the
manufacturer code) of the MAC address are used.
The following example shows a new directory '000e7f' for a Broadcom adapter. If it had
been possible to read the name from the SMB BIOS, the directory would have been called
BroadcomNetXtremeEtherlink or similar.
Abbildung 72: PXE templates directory
Now you can copy the NDIS driver belonging to the network card to the directory
..\PXETemplates\000e7f
Navigate to the directory ..\OSDepot\Support\FpyMaker\Connect\Microsoft IP and
NETBEUI\Broadcom 10-100 Nextreme and
copy the Connect directory and all subdirectories as well as the file driver.txt to the
directory ..\PXETemplates\000e7f
Your client will load the driver assigned at the next PXE boot.
Important
This works only from Columbus version 6.4 with hotfix 1 (please contact Brainware for
the current files)
If you use an LMHOSTS file, you must store this in every \Connect\msnetdrv directory.
Chapter 5 Getting to grips with OS deployment 117
Finding network components causing errors
Customers have told us that they were able to use PXE in their test environments without
any problems, but that they are now experiencing problems in the production network,
with the same computers and Columbus settings. A wrongly configured switch or router, or
even just a different time characteristic can often prevent PXE from functioning correctly.
For example, the Spanning Tree function in new Cisco switches must be switched off, or the
IP Helper function must be activated, ports must be open, name resolution must be
working, etc. You will need to consult the networking team specialists.
PXE is also more susceptible to network problems such as switches, routers or even cabling.
A damaged cable could still carry normal network traffic because the error protocols are
more developed. PXE, however, cannot deal with this and crashes immediately with various
errors if network problems occur. No customer would change their entire cabling due to
PXE problems - but how should one proceed?
The easiest is to isolate the suspected components. First of all, connect the computer
directly behind the server and test whether PXE functions; this is usually the case. Then
attach the computer behind the router, in the next segment etc. until PXE no longer
functions. Following this, check the intermediate components and replace the switch or
router, for example. If this still does not help, try using another cable for this device.
Hard disk images
OS Deploy can take advantage of hard drive images (so-called 'cloning'). The leading
product here is Symantec's 'Ghost' (www.symantec.com) and Drive Image from PowerQuest
(www.powerquest.com).
We do not recommend building up a computer by means of the 'cloning' process as it
becomes difficult to manage a cloned environment after 1 or 2 years. 'Cloning' in
conjunction with OS Deploy can offer the advantages of both worlds.
The imaging solution in OS Deploy can be used to backup important machines on one
server.
To do this, use the Special tab in the console to create or restore partitions. You can make
use of these functions by means of the boot diskettes, via the 'Reload/Create Disk Images'
menu item.
Important: Ghost and Drive Image are not part of the Columbus software and must be
acquired separately.
118
Columbus OSDeploy
Preparing a disk image for OS deployment
You can also create a disk image by means of OS Deploy, which will later save you time
when setting up other computers with this image. For this, set up a computer as if you were
building it normally. In addition to the jobs that you require, you need to select the
jobPrepare system for imaging in the Jobs tab. After this, stage the computer as normal. When
the image below appears, the computer has reached a stage where you can make any other
desired modifications to the system. You can pre-install applications, make configuration
settings, etc. When you have completed this, click on Image Now.
Abbildung 73: Imaging - Maschine vorbereiten
This will generate a PXE action to backup the hard disk. Your computer will reboot and a
disk image of the computer will be created after restarting by means of PXE.
In the console you have to refresh the OSDeployment agent in the infrastructure view. After
that, You can may use this image for staging new computers; naturally only when the
hardware of the other computer is the same as the hardware on which the image was
created.
Chapter 5 Getting to grips with OS deployment 119
Creating an image
Select this computer in the console in the Computers window.
Select the Specialtab and the Disk imaging option
Select the operation Backup hard disk if you want to create an image of the entire disk.
Select the operation Backup system partition if you just want to use the operating system to
create an image of the first partition.
Click on Apply to switch on the computer via WakeOnLan and to generate the image.
The Image directory
Disk images are stored in special directories in OS Depot.
120
Columbus OSDeploy
Folder/file
computer.img
Description
The directory containing the necessary files and
structures for imaging computers that have no
configured release.
This directory allows you to create/play back
images when using boot diskettes.
Release\Images
The directory containing the required files and
structures for hard disk imaging for a particular
release.
Every release has its own image directory. If a
computer is assigned to a release, the images are
created in the corresponding release.
AMenu.bat
The batch file that makes the menu available
when using diskettes.
The batch file that starts the imaging tool
Image.bat
params.txt
The parameter file in which the imaging tool to be
used can be configured.
release.txt
The text shown in the Release menu when using
diskettes. The text can be modified as required.
> Reload/Create Disk Images
[MacAddress]
The generated images are stored in a directory,
which contains the MAC address of the computer
in 8.3 notation. (The first character of the MAC
address is skipped). In this folder you'll find a file
image.ini, which contains the netbios name of the
computer.
Paragon
This directory contains the Paragon disk imaging
tool, which is a part of Columbus.
Ghost
This directory contains prepared scripts for the
Ghost disk imaging tool, which must be
purchased separately.
Important: The imaging tool that you choose must be entered in the params.txt file. The
name must correspond to the name of the folder containing the imaging tool. Currently,
Symantec Ghost and Paragon are supported. Other tools can be easily integrated.
Chapter 5 Getting to grips with OS deployment 121
CHAPTER 6
Security
Once your installation is running smoothly you should implement security settings on your
system.
In this chapter
Release security..................................................................................... 123
Directory security.................................................................................. 123
Columbus account ............................................................................... 124
Release security
Directory
Release
Rights
Columbus
Columbus
Everyone: change
Some companies restrict the use of the group 'Everyone'. 'Domain users' should be used in
this case.
Directory security
The Columbus account (or the account used for this) should have read access to the OS
Depot directory and all subdirectories.
The Columbus account must have modification rights to the Profile directory of the
respective site in order to store the Profiler profiles.
Directory
Authority
OSDepot\[Release]\SITE\[Site1]\Profil Columbus: change
e
OSDepot\[Release]\SITE\[Site2]\Profil Columbus: change
e
OSDepot\[Release]\SITE\[SiteX]\Profil Columbus: change
e
123
The Columbus account must have modification rights to the Images directory of the
respective site in order to store images.
Directory
Authority
OSDepot\[Release1]\Images
Columbus: change
OSDepot\[Release2]\Images
Columbus: change
OSDepot\[ReleaseX]\Images
Columbus: change
Columbus account
The Columbus account (or the account used for this), must not be an administrator in the
corresponding domain. Ordinary user rights are sufficient. The only exception is that the
user account must be able to set up accounts in the domain. Where some computers are
often set up again (e.g. test computers), it is advisable for the Columbus account also to be
able to add computers to the domain again.
Note: Where computers were added by an administrator of the domain, it is possible that a
user with non-administrative rights may not be able to add a computer to the domain
again.
124
Columbus OSDeploy
Index
A
About tab • 56
About this manual • 3
Adding additional operating systems • 10
Adding connectors • 91
Adding keyboard layouts • 96
Administering OS Deploy jobs • 85
Allow remote administration functions • 115
B
BIOS update • 114
Boot diskette successfully created • 43
C
Changing the boot diskette • 98
Changing the intro screen • 97
Changing the Microsoft client • 93
Check the policy entries in Windows 2003 servers •
114
choices.ini • 70
Columbus account • 124
Columbus OS Deploy • 5
Columbus PXE filtering • 111
Columbus System Settings • 11
Columbus.ini • 72
Completing the configuration • 58
Configuration • 65
Configuration tab • 51
Configuring Floppy Maker • 86
Configuring infrastructure services • 102
Converting an emergency diskette back to a normal
boot diskette • 97
Create diskette • 40
Creating a boot diskette • 34, 42
Creating a boot diskette image • 59
Creating a driver job • 82
Creating a job • 80
Creating an image • 120
D
Description of the directories • 86
Designating the computer • 48
Directory security • 123
Diskette requirements • 34
Do you want to send us information? • 4
Driver job • 80
Driver job structure • 80
E
Emergency diskette • 57
Entries in options.ini • 73
Evaluating the filter file • 113
Example File PXERules.txt: • 113
Extras tab • 54
F
Filter file setup • 112
Finding network components causing errors • 118
Floppy Maker • 59
Format diskette • 41
G
General • 26
General tab • 49
Generating the image • 59
Getting to grips with OS deployment • 63
H
Hard disk images • 118
Hardware • 28
How to migrate? • 101
I
Image successfully created • 62
Important differences • 99
Insert diskette • 61
Installation options • 9
Integrating computers by means of PXE • 20, 22
Introduction page • 44
J
Job components • 76
Jobs • 29
Jobs tab • 53
L
LMHOSTS file • 116
M
Master boot diskette • 98
Method of installation • 31
Microsoft IP and NetBEUI • 92
Microsoft OEM extensions • 79
Migration of AutoSetup environmments • 3, 99
Modifications to the boot diskette • 87
N
Naming standards • 77
Naming the image • 60
Native NDIS driver and PXE • 117
Network • 27
Networking tab • 50
125
O
Optimizing a driver job • 83
Options.ini • 72
OS Deploy jobs • 14, 76
OS deployment • 103
OS Deployment dialog • 12
P
U
unattend.txt • 75
Updating a OSDepot • 13
W
Partitioning • 45
Post setup processing • 79
Pre-Boot Execution Environment (PXE) • 107
Preboot services • 107
Preparing a disk image for OS deployment • 119
Pre-setup processing • 78
Profiler • 47
Protocols tab • 51
PXE and OS Deploy • 109
PXE images • 108
R
Record computer manually • 21
Refreshing the database • 15
Regional job • 83
Release security • 123
Releases • 67
S
Security • 123
Selecting a release • 46
Selecting parameters • 39
Selecting site and config • 47
Selecting the boot image • 36
Selecting the Computer • 23
Selecting the connectors • 37
Selecting the keyboard • 38
Selecting the partitioning schema • 38
Setting up computers • 19
Setting up job.ini • 76
Setting up OS deployment • 9
Setup with boot diskettes • 34
Setup with Columbus Console and PXE • 19
Sites & configs • 14, 68
Staging a computer by means of a boot diskette • 43
Staging one computer per console • 24
Starting Floppy Maker • 35
Starting the installation • 32
Structure • 66, 68
Structure of a regional job • 84
Structure of the boot diskette • 98
SW distribution tab • 55
SW management • 30
T
Tailoring the OS Deploy configuration • 14
tcpip.ini • 74
Terms used • 6
The directory structure • 86
The Image directory • 120
The infrastructure services can be configured as
follows • 102
The parameter file • 88
126
The PXE filter file • 112
Troubleshooting OS deployment • 113
Typographical conventions • 3
Index
WakeOnLan • 108
Welcome to Columbus <Product_MajorVersion • 3
What is the potential of PXE filtering • 111
Y
You can reach us as follows • 4