GK Finalproj

Department of Cybernetics & Virtual Systems
Final Year Project Report

For the degree of
Computer Systems Administration
By
Geoff Kendal
Unattended workstation deployment
Supervised by David Forbes

2006
Final Project Report
Geoff Kendal (UB: 02002096)
UNIVERSITY OF BRADFORD
Department of Cybernetics, Internet and Virtual Systems
Final Year Project
DECLARATION OF ORIGINALITY
Declaration
I understand that all my project work must be my own unaided work. If I make
use of material from any other source I must clearly identify it as such in any
interviews, reports or examinations. I understand that my reports must be
written unaided in my own words, apart from any quoted material, which I
must identify clearly in the correct manner.
I understand that the work, which I shall present for assessment must be work
carried out by myself only during the project period, which has not been
previously prepared. Where any such previous work is made use of in the
project, I shall make this clear in any interviews, reports or examinations.
I understand that violation of these conditions may result in a mark of zero for
the component or components of assessed work affected.
Print name:
Signature:
Date:

Abstract
For companies and organisations that run large computer networks, manually
installing and/or rebuilding desktop workstations is not a viable option, as it
takes a considerable amount of time per machine, which can quickly consume
company resources and increase the TCO (Total cost of ownership) for each
workstation.
For my final year project, I have proposed to implement a solution that will
enable automated deployments to any workstation (with varying hardware).
The automated deployments should include a common business operating
system, along with the most recent service packs, patches, applications and
miscellaneous configuration modifications. The system should also be
relatively easy for a competent technical user to maintain, and keep up to date
(software updates/patches etc.). This system will allow IT departments to run
much more efficiently and should significantly reduce support and system
maintenance costs.
For the deployments a very basic development network has been used, along
with the open source unattended project to successfully deploy Windows XP
professional along with the associated patches, applications and
configuration modifications to a variety of clients. The final solution can be
quite easily incorporated into most corporate networks, as the required
infrastructure will already be in place. It will also not add any additional
licensing costs, as all the software used in the project is open source and free
to use.
Keywords
Administration, Installation, Deployment, Automation, Scripting, Operating
System, Network, Client, Server.

Table of contents
1. Introduction....................................................................................................5
2. Project resources...........................................................................................5
3. Progress of the project...................................................................................6
3.1 Investigation of operating systems..........................................................6
3.1.1 Choosing the version of the operating system..................................6
3.2 Applications and utilities to deploy...........................................................7
3.3 Methods of deployment............................................................................7
3.4 Infrastructure preparation.........................................................................8
3.4.1 Adding the operating system.............................................................9
3.4.2 Booting from the network..................................................................9
3.5 Specifying installation options................................................................10
3.5.1 Windows setup options...................................................................10
3.5.2 Unattended script options................................................................11
3.5.3 Naming the client machine..............................................................11
3.6 Updating Windows.................................................................................12
3.6.1 Slipstreaming the service pack.......................................................12
3.6.2 Adding patches and updates...........................................................12
3.7 Adding applications................................................................................13
3.7.1 The install script...............................................................................13
3.7.2 Installing applications......................................................................13
3.8 Configuration modifications....................................................................15
3.8.1 Updating the start menu and desktop.............................................16
3.8.2 Registry modifications.....................................................................17
3.8.3 Other modifications.........................................................................18
3.8.4 Applying to the default user.............................................................18
4. Project management....................................................................................20
5. Conclusions.................................................................................................21
6. Recommendations for further work.............................................................22
6.1 Configuration based on MAC address...................................................22
6.2 Different application sets........................................................................22
6.3 Keeping the server up-to-date...............................................................22
6.4 Configuration stored in a database........................................................22
References.......................................................................................................23
Appendices......................................................................................................24
Appendix A Pxelinux configuration file......................................................24
Appendix B Unattend.txt configuration file................................................25
Appendix C Machine naming script..........................................................27
Appendix D Example registry file..............................................................28
Appendix E Network status icon script.....................................................29
Appendix F Gant chart..............................................................................30

1. Introduction
Many computer users have undoubtedly encountered the situation where a
serious problem has occurred on their system, or the system is just running so
slowly that it has become unusable, and as a result of this have had to
reformat (rebuild) their machine. This process of reloading the operating
system along with all the additional patches, applications and utilities, then
configuring everything as required can take many hours. It also requires a
user with an in-depth technical knowledge to be present to perform the
rebuild. As this is such an infrequent event for most home users, it can be an
acceptable solution to the problem. However, in a corporate environment
where there might be hundreds, or possibly thousands of machines, installing
each one manually is simply not a viable option due to the amount of time
required per machine.
If the rebuilding process could be automated it would remove the requirement
for a technical user to be present throughout the rebuild. It will also
significantly lower IT support costs, as IT staff will be able to use their time far
more efficiently. Automating rebuilds can further help to reduce support costs,
as in environments where no files are stored on local workstations (such as
the university for example), it is quicker and much more efficient to rebuild a
faulty machine, rather than having IT staff diagnose and attempt to fix the
problem. As rebuilding systems in this manner uses very little staff resources,
it means machines can be regularly rebuilt, which will help them to keep
running as fast as possible, and will ensure that machines have all the latest
versions of the software installed.
For my computer systems administration final year project, a system has been
implemented that will enable automated workstation deployments/rebuilds
over the local network. These installations deploy the Windows XP
Professional operating system, including the most recent service pack and
any other required patches. In addition to this a selection of common
applications are installed, such as Microsoft Office and Adobe Acrobat
Reader.
2. Project resources
For the development of the project a simple network was used that comprised
two standard 1.5GHz PCs. The first PC was to act as a client machine that
will be deployed; the other machine was to act as the server for the
deployments. Both machines were connected via a cheap 100MBit network
switch. The use of a larger scale network for deployments was also
investigated. Numerous software packages were also used in the
deployments; these are detailed throughout this report.

3. Progress of the project

3.1 Investigation of operating systems
The first decision that was made regarding the deployments was which
operating system (OS) should be deployed to the clients. This should ideally
be a popular OS that most users are comfortable and familiar with. After some
research on the internet, the information found was hardly surprising.
Microsoft is the clear market leader in the desktop OS sector, with a huge
93.8% market share in 2002. At this time its Windows server products also
had a 55.1% share of the server market. [1]
It is clearly obvious that Microsoft provides the most widely used range of
operating systems, so it was decided that one of these would be used in the
deployments.
3.1.1 Choosing the version of the operating system

The key aspect of choosing the version of the operating system to deploy is
what Microsoft call Lifecycle support. [2] This is how long the vendor will
continue to support the OS, this includes service packs and updates etc. This
is very important to any business, as if they invest in 1000 Windows 2000
licences and they then become no longer supported, it will effectively force
them to pay for an upgrade to a supported product in order to maintain system
security, as updates will no longer be issued for the original product.
The following table (Figure 1) shows the lifecycle support dates for each of
Microsofts business grade operating systems (Windows 95/98 etc. are
designed for home, not business use).
Product Name
Release Date
Main Support
End Date
Extended
Support
End Date
Windows XP
Professional
31st Dec 2002
31st Dec 2006
31st Dec 2011
Windows 2000
Professional
31st Mar 2000
30th Jun 2005
30th Jun 2010
Windows NT4
Workstation
29th Jul 1999
30th Jun 2003
30th Jun 2004
Figure 1 Windows Lifecycle Support
The table clearly shows that the most viable option is Windows XP
Professional, as if it was deployed today; it would still continue to be
supported for another 5/6 years.

3.2 Applications and utilities to deploy

For the deployments, only a limited selection of applications and utilities will
be installed. This will produce a useable final system, with a generic set of
applications; specialist applications will not be installed by default on the base
system, as they will not be required by all users.
After interviewing a selection of both advanced and intermediate users, the
following list of applications and utilities to install was produced:
Microsoft Office 2003 Professional

AVG Anti-Virus
Windows Media Player 10
Codec Packs (MP3, MPEG-4, DivX, etc.)
Sun Java Virtual Machine
Macromedia Flash Player
Macromedia Shockwave Player
Abobe Acrobat Reader
MSN Messenger
WinRAR
Putty (SSH Client)
3.3 Methods of deployment

For performing the deployment, there are two key methods, these being CD
and network based deployments. CD deployments contain all the required
files for the installation on the disc, and the CD must be present throughout
the installation for this reason. Examples of CD based deployments include
aspects of Microsofts deployment tools [3] and the MSFN Windows CD [4].
While CD based installs can work well, they are not appropriate for this
system, as a CD will be required for each machine being rebuilt. A network
based deployment is a far better solution for our scenario, as a large number
of machines can simultaneously be deployed from one source, and the source
is not limited by any size restrictions.
After researching methods and techniques of network based deployments, it
was concluded that there were two key routes that could be taken. The first
being the open source route, which was led by a solution called The
Unattended Project [5]. The second and more commercial option was from
Microsofts Remote Installation Services [6].
The main differences between these solutions are outlined in the following
table (Figure 2):

Unattended project
Open source
Microsoft RIS
Commercial software
Runs on Windows or Linux servers
Requires Microsoft domain infrastructure
Script based installation
Image based installation
Easy to integrate new patches
Harder to integrate new patches
Slower installation (~=2 hours)

Fast installs (~=30 min)
Figure 2 Network deployment comparison
While Microsoft RIS offers a much faster deployment time, this is a less
important strength than those offered by the unattended project, as it is likely
that deployments will happen out of hours to avoid any disruption to users.
The unattended project also is far more adaptable than the Microsoft solution,
as it can run on a range of servers, and have additional software and patches
added in a matter of minutes, due to it being script based. Doing the same
using Microsoft RIS would involve deploying a machine, installing the patch,
taking an image of the machine, then pushing it back to the RIS server, which
is a great deal of work for just adding a new patch to the system.
3.4 Infrastructure preparation

There are only two key prerequisites required in order to run the unattended
project; a DHCP server (for allocating IP addresses and other information),
and a fileserver (Deployment server) to store all the setup files.
The deployment server can be
prepared once the requirements
above have been met. It was
named ntinstall, as this is the
default machine that the clients
will look for. It was not essential
to call it this, but just prevented
further configuration later in the
project.
A read only, guest accessible
share was then created on the
server called install. This is
where all the deployment files
reside. Once this had been
created, the unattended project
source files were then download
from the project website [5] and
then extracted to a temporary
location. From this temporary
location, the contents of the
install directory were then copied
Figure 3 The install share

8
to the install share on the deployment server. At this stage, the share was
tested across the network, using the UNC path \\ntinstall\install (Figure 3).
3.4.1 Adding the operating system

The infrastructure is now in place, but the deployment server has no operating
system to serve out to clients. Adding the operating system is an easy task,
inside the os directory, a new directory should be created with a name that
describes the operating system that will be added. A good name in this
instance would be winxp. Once this directory has been created, the i386
directory from the windows CD should be copied here, so there is a directory
structure similar to install/os/winxp/i386. It is possible to have a selection of
different operating systems on the server, as the installation scripts
automatically detect the OS, based on the contents of the i386 directory.
3.4.2 Booting from the network

The most efficient way to initiate the deployment is via a network boot, this is
also sometimes referred to as a PXE (Pre-boot eXecution environment) boot.
By booting from the network, a deployment can be initiated with a users bare
hands, eliminating the requirement for any boot CDs. The ability to boot from
a network depends upon if the network card supports it or not. Most on-board
network cards support this, and can be configured appropriately from within
the systems BIOS. The network boot option should be set as the first boot
device, followed by the hard disk so that if the network boot fails, the system
can still successfully boot. Should the system not support network booting, the
deployment can still be started using the unattended Linux boot CD.
The network boot downloads its initial OS from a TFTP (Trivial FTP) server, so
the network will require an accessible TFTP server. Most distributions of Linux
include this in the xinetd package, for Windows tftpd32 [7] can be freely
downloaded. The contents of the bootdisk/tftpboot directory in the
unattended project source should then be copied to the root folder of the
TFTP server. In addition to this, the contents of the linuxboot/tftpboot should
also be copied to this directory (These can be found in the unattendedlinuxboot.zip file), these files are the pxelinux configuration files, and the boot
image files. The boot image is a small Linux distribution (about 20MB in size),
that loads the network drivers, then connects to the install share, and starts
the Windows installation.
The networks DHCP server must also be reconfigured in order for it to hand
out additional information to clients. The next-server option (or 066 in
Windows) should be set to the IP address of the TFTP server, and the
filename (Windows option 067) should be set to pxelinux.0. These
configuration changes will tell clients booting from the network which file they
should try and boot from, and where it can be located on the network.

Finally, the configuration file that resides on the TFTP server should be
modified, as by default it boots straight into an installation. Due to the fact the
client machines will be set to boot from the network, this is undesirable, as the
clients will start a new installation every time they boot up. A new configuration
file was created (Appendix A) which will give the user a two second prompt to
type in a password (buildme) that will initiate an installation. If an invalid
password is entered, or there is no input in the first 2 seconds, the client will
boot locally. This file could have additional information appended, in order to
make different deployments available.
Figure 4 The network boot process
3.5 Specifying installation options

Clients are now able to initiate a network install by booting from the network
and entering buildme within 2 seconds at the boot: prompt. However this
installation is not unattended, as the unattended scripts and the Windows
setup still ask the user a number of questions throughout the installation.
3.5.1 Windows setup options

All of the questions that need to be answered during Windows setup can be
automatically answered, via use of the install\lib\unattend.txt file. Other
Windows options that are not mentioned during setup can also be set in this
file, which saves time later during the installation process. Microsoft provides
10
detailed information [8] for the Windows 2003 unattend.txt, which also mostly
applies to Windows XP and 2000. The unattend.txt file that was produced for
the deployments is included in Appendix B.
3.5.2 Unattended script options

In addition to the options that Windows setup reads from the unattend.txt file,
there is also a meta section that provides options for the unattended scripts,
such as disk formatting options, and selecting which applications to install
after the Windows setup has completed. These options are documented on
the unattended website [9]. The configuration that was used can again be
found in Appendix B. This configuration repartitions the entire hard disk as C:
and runs the full.bat script after the Windows setup is complete.
Should there be a requirement to provide different options to certain clients, it
is possible to store the options in a CSV file, or SQL database along with the
MAC address of the client.
3.5.3 Naming the client machine

As all of the clients will be using the same configuration file for Windows
setup, they will all be assigned the same machine name, which will cause
serious conflicts on the network. In a domain environment, it is also likely that
this would prevent from them being able to join the domain. A solution was
required to assign each machine a unique name. The easiest fix for this
problem is to assign the machine the name *. This will cause Windows setup
to automatically generate a name based around the MAC address of the
machine. This is a solution to the problem - however, it gives no control over
the naming of the clients.
The unattended scripts include a file called config.pl; this script can be used
to dynamically generate options for the unattend.txt file. As part of the
example usage for this, a script was included that looked at the reverse DNS
entry of the assigned IP address, then took the section before the first .. This
script worked very well, apart from the fact that it would fail if there was no
reverse DNS entry for the IP address. In order to remedy this, the script was
rewritten so that if there was no reverse DNS entry, the value from the
unattend.txt would be taken (e.g. workstation), and the last section of the IP
address was added. The rewritten script is included in Appendix C.
Naming machine with reverse DNS:
192.168.50.106 dyn-106.int.squiggle.org dyn-106
Naming machine without DNS:
192.168.50.206 ?????? workstation + IP workstation206

11
3.6 Updating Windows

A standard installation of Windows XP does not include any security updates
or patches; this means that any deployed systems are left in a vulnerable
state from crackers, worms and viruses. In order to minimise the time that
systems are left in this state, the operating system should be updated as soon
as possible.
3.6.1 Slipstreaming the service pack

Service packs can be slipstreamed into the Windows setup files [10]. This
means that as soon as Windows has been installed, the service pack is also
in place as well. This procedure also has other favourable benefits, such as
reducing installation time, and giving the system a smaller footprint. The most
recent service pack for Windows XP Professional is SP2. The full version of
this service pack was downloaded, and integrated into the Windows XP
installation directory on the deployment server. The containing directory was
then renamed to winxpsp2 to reflect this change.
3.6.2 Adding patches and updates

Slipstreaming patches into the Windows installation directory is a harder task
than the integrating service pack, as there are several different types of
patches, and not all offer this functionality. In addition to this, new patches are
constantly being released by Microsoft. An easier solution to maintain is
scripting the installation of the required patches as soon as the Windows
installation has finished.
A list of patches for Windows XP SP2 can be found in the scripts directory of
the deployment server in the winxpsp2-updates.bat As the list of patches is
constantly being updated it is advisable to obtain the latest version of this file
from the CVS repository of the unattended project website. This will ensure
that deployments have the most recent patches in place, it is also advisable to
regularly update this file.
Once the file containing the list of updates has been obtained, each of these
updates should be downloaded and placed in the appropriate directory on the
deployment server. The formatting of this file contains all the required
information for this task, as each update has a line of the following format:
:: URL|<language-code>|<download-url>|<deployment-server-directory>
As the deployments are only intended for a UK environment, updates with the
language code ENU or ALL will only need to be downloaded.
The winxpsp2-updates.bat also contains the relevant commands to script the
installation of these patches in an unattended way. This is generally done by
12
appending /passive /n /norestart to the command, these command line

arguments instruct the installer to only show the status bar, not backup any
files, and not restart after installation. As mentioned earlier, several of the
patches do not use the same installer, so require slightly different command
line arguments. The available arguments can usually be obtained by using /?
as an argument.
As all the Windows updates have now been added to the system, it would be
a good time to perform a defragmentation on the hard drive of the client. This
will cause all the Windows files to be relocated to adjacent sectors of the hard
drive, rather than being distributed around the entire disk. This process will
increase the performance of the finished system; the defragmentation is
initiated by calling defrag.bat from the main full.bat script.
3.7 Adding applications

A fully patched and unattended installation of Windows XP can now be
deployed to clients across the network. The next stage is to install the
applications and utilities that were listed in section 3.2, this process is aided
via use of the install and to-do scripts of the unattended project.
3.7.1 The install script

The install script that is included with the unattended project takes care of
managing the installation of packages after the Windows setup has
completed. Its first task is to install ActivePerl - this is a free distribution of
Perl for Windows and by installing this, the client is able to run the rest of the
unattended scripts. The next script to be processed by the installation script is
whatever was specified in the meta section of the unattend.txt configuration
file. As can be seen from Appendix B, the script full.bat was specified, which
in turn calls other scripts. As the scripts are processed, a to-do list is created
on the clients disk (C:\netinst\todo.txt). This list is in a stack formation, i.e.
new commands are inserted at the top of the list, and when it is processed,
the top command is removed and processed first. This means that commands
will be executed in the opposite order from which they were added. By using
this file, the list of commands required to install the applications is maintained
across system reboots.
3.7.2 Installing applications

The main script (full.bat) calls all the individual scripts for each of the specific
applications to install, which in turn execute the commands required to install
the application in question. Keeping each applications installation commands
limited to their own script makes managing the system much easier, and also
allows them to be called from different master scripts, i.e. sales.bat or
managers.bat.
13
The commands to install applications are similar to those used to install the
Windows patches. There are several key installers used by software vendors
to distribute their software, generally each installer shares the same command
line arguments regardless of what application it is being used to distribute.
With the majority of installers, command line arguments can be listed by
running the installer with the /? argument. The installer vendors website
usually has a comprehensive guide of command line arguments that can be
used, even if the installer itself wont easily reveal them.
Figure 5 The Windows installer command line arguments
An example of the command required to install the codec pack package is:
> klmcodec145.exe /SILENT
When this is inserted into a script, it must pass this command along with the
full path to the script that manages the to-do list:
> todo.pl "%Z%\packages\codecs\klmcodec145.exe /SILENT"
This includes a variable for the Z: drive which is a drive mapping on the client
to the install share on the deployment server.

14
Should obtaining a working set of command line argument be unachievable,

there are still a few less desirable options that can be taken. The first of these
options is repackaging, this is where the status of the machine is logged in
detail, before and after the application in question has been installed. By
making a comparison between the two states, it is possible to determine
exactly what was done by the installer, and subsequently reproduce these
changes by creating a new installer that can be instructed to run in an
unattended fashion. While this seems like a satisfactory solution, it is far from
ideal, as the installer may add certain files depending on if other applications
are installed, or if certain hardware is present, which could lead to an
incomplete install of the application in question. In addition to this, the
application will need to be repackaged each time a new version is released,
whereas it is normally a case of replacing the old installation file with the
updated one, and checking that the command line arguments still work.
The alternative to repackaging applications is by using a tool that can simulate
key presses and mouse clicks. This task can be performed by using VBScript,
or a utility included with the unattended files AutoIT. Again this method also
not ideal for our deployments, as while it may provide better installations that
repackaging, the vendors may change the options in the installer, causing a
rewrite of the AutoIT script, which could take some time, depending on the
complexity of the installer.
Certain applications have special methods for mass deployments; an example
of this that was encountered was the anti-virus software AVG 6 free edition.
In order to perform an unattended installation of this application, the vendor
supplies a tool called AVGADMIN 6. This tool allows a customised setup to
be created based on the options specified when running the admin tool. As
above, the downside to this is that the whole process needs to be repeated
each time a new version is released, although this isnt such a major problem,
due to the fact that AVG automatically keeps itself up to date whilst updating
its virus definitions.
It should be noted that unattended project is currently in the process of
moving licence keys out from the application installation scripts, to a central
location (site/keys.bat). This will allow all the licence keys to be easily entered
in one location. At present, only the Microsoft Office (2000/XP/2003) and
Microsoft Visual Studio application suites make use of this new system.
3.8 Configuration modifications

After the operating system and all the required applications and utilities have
been installed, the setup of the deployment is still not complete. The system
should now perform any required configuration changes to the system so that
these do not have to be performed manually. In a large corporate network that
uses a Microsoft domain infrastructure, these changes can usually be
automatically applied to all network clients via means of group policy objects
15
(GPOs). The deployment system being developed is intended for any

network, so it is not presumed that a domain is in place, therefore
configuration changes will be made locally to each client. Modifications to the
systems configuration are usually easier than performing the installation of the
applications, as all that is involved is changes to the registry, or updating the
file system.
3.8.1 Updating the start menu and desktop

When each application is installed, it will usually create a folder on the start
menu, containing shortcuts the application, its documentation, and sometimes
an uninstallation utility. In addition to this, some applications also place a
shortcut on the desktop. If all the shortcuts that applications created were
kept, our system would appear very cluttered soon after the deployment, so it
is a good idea to remove any shortcuts that arent necessary. Examples of
these include the Adobe acrobat reader desktop icon, and the codec pack
start menu group. Generally, if a user wishes to open a .pdf file, they will open
it from a webpage, or click on the file both actions will start acrobat reader,
which eliminates the requirement for a desktop icon. The codec pack contains
some shortcuts to some quite advanced tools that the majority of users will
never need to use, so the start menu program group for this can be removed.
The programs will still be present on the system in the installation directory if
they are ever required.
In addition to removing certain shortcuts, it may be the case where shortcuts
are best placed in another location. An example of this is Windows movie
maker, and Windows journal viewer. These are initially placed in the
programs (top level) folder of the start menu, when they would be more
ideally positioned in the accessories folder of the start menu. Instead of
issuing a delete command to these shortcuts, they can be simply moved into
the appropriate folder.
As mentioned earlier, it is advisable to keep all installation commands related
to each application in their respective script file. This should include any
commands that modify the start menu and desktop items associated with the
application. When updating the script files to reflect the desired changes, it
should be noted that the commands in the script a processed in reverse order,
i.e. from the bottom upwards. To take the earlier example of the installation
script for the codec pack, the script now looks like the following:
> todo.pl "rmdir /s /q \"C:\Documents and Settings\All Users\Start
Menu\Programs\K-Lite Codec Pack\""
> todo.pl "%Z%\packages\codecs\klmcodec145.exe /SILENT"
It is essential that the commands to modify the start menu and desktop items
are above the installation commands, as if they are executed before the
installation takes places, the files they intend to manipulate will not yet have
16
been created and the command will be unsuccessful. If long filenames are
being used, such as in the case above, they should be enclosed between
quotes, however, as the command is already enclosed in quotes (for being
passed to todo.pl, the quotes inside this command will require escaping with a
backslash, so that each quote is replaced with \.
3.8.2 Registry modifications

If certain changes are required to the configuration of applications or the
operating system, the most likely place for these options to be set is from
within the system registry. The registry is a database in Windows that contains
thousands of configuration options for both Windows and any installed
applications. The registry is structured in a similar way to Windows explorer
in a tree like system, this makes locating registry keys fast and efficient as
they are usually located in logical positions within the registry. The registry can
be accessed by running the system registry editor (c:\windows\regedit.exe).
This tool allows browsing, searching and editing of the registry. An example of
the registry key that sets whether or not the user has accepted the privacy
agreement for Windows media player is shown below:
[HKEY_CURRENTUSER\Software\Microsoft\MediaPlayer\Preferences]
"AcceptedPrivacyStatement"=dword:00000001
Setting this value to 1 causes Windows media player to believe that the
privacy agreement has been accepted. As a result of this it will not display this
to the user after the client has been deployed.
Microsoft provides an easy way for updating data in the registry, via a means
of .reg files (See Appendix D). These files contain the location, name, type
and data of each registry key. If a file containing valid registry information is
opened, Windows asks the user if they wish for the data to be added into the
registry, this can be performed on the command line as follows:
> regedit.exe modification-file.reg
However, this method still asks for user confirmation before adding the data
into the registry. The dialogue box can be suppressed by adding the /s
argument to the regedit command:
> regedit.exe /s modification-file.reg
From time to time finding the registry key that corresponds to an option in an
application can be quite a challenge, luckily there a few easy methods of
obtaining these keys. The first and most effective of these, is to use an
uninstaller utility, or a repackaging tool (as mentioned earlier in this
document). These can take a snapshot of the system before the option is
modified, and another snapshot afterwards, then compare the differences and
determine which registry keys were changed as a result. Many websites also
17
publish information on where certain options can be located in the registry - it

is just a matter of searching. Finally, software vendors can be very helpful in
supplying this kind of information, even if they cant help straight away, they
can usually contact one of their software engineers who will able to assist.
3.8.3 Other modifications

While the majority of the required modifications to the system were
successfully made via a means of file or registry manipulation, there were a
few modifications that had to be performed by making use of other methods.
An example of an alternative method is when a command line utility can make
certain configuration changes that are usually performed using the GUI. A
utility such as this is the Windows netsh command. This command has the
ability to configure many of the network settings within Windows. In this
particular instance, it was used to alter the behaviour of the Windows firewall,
as by default it blocks ping requests (ICMP echo). By using the following
command line arguments, the netsh command was able to allow the client to
respond to pings.
> netsh firewall set icmpsetting type=8 ENABLE profile=ALL
Another modification that was required was the enabling of the network status
icon in the system tray. It was initially presumed that this would be a simple
registry modification; however a slightly more complex solution was required.
This was due to the fact that a client may have multiple network interfaces,
and the icon setting is unique to each interface, this means that there isnt one
definitive registry key that can set this. After some investigation, a batch file
was found that would add all the appropriate keys into the registry to enable
the status icons. Unfortunately, the author of the script could not be
determined, however, it has been included in Appendix E.
3.8.4 Applying to the default user

Once all the required configuration modifications had been made to the
system, it was thought that the deployment system was fully complete, as
when the Administrator user logged into the system, the desired configuration
was clearly visible. It was only after the client machine had been properly
used when quite a major problem with the deployments was discovered.
Any modifications to the systems registry beneath the HKEY CURRENT
USER tree, as the name suggests, only apply to the user currently logged on.
Once another user is created and logs on, the system resets this tree to all
the default settings once again. The reason for this is because each users
registry settings are held in a file called ntuser.dat in the users profile
directory, this file is also known as a registry hive. When the system logs the
user on, it loads the appropriate registry hive into the HKEY CURRENT
USER tree. Windows does store a registry hive for the default user; this is the
18
template that is used to create new user accounts. However, this file cannot
be accessed through the registry be default, in order to access it, the hive
must be loaded into a new tree of the registry. This can be done with the
following command:
> REG LOAD HKU\TempHive "C:\Documents and Settings\Default
User\ntuser.dat"
This command simply loads the specified registry hive file, into the HKEY
USERS\TempHive tree of the registry. Any changes performed in HKEY
CURRENT USER must also be performed in this tree as well, so that they
will be applied to the default template. Once all registry modifications have
been made, the hive is simply unloaded via the following command:
> REG UNLOAD HKU\TempHive
It should also be noted that the default user profile, also has several desktop
items, and start menu items that may require modifications, although this is a
much simpler task, as the files are directly accessible.

19
4. Project management
From the very start of the project, time management was a key factor that was
heavily utilised to help ensure that the project ran according to the
predetermined schedule and that it was completed on time. The time available
for the project was managed via means of a Gant chart that was produced in
the very early stages of the project. A copy of the Gant chart can be found in
Appendix F.
The project target objectives were originally specified as follows:
Allow a popular workplace operating system to be deployed without the

need for IT staff to be present throughout the installation.
Deployed systems should have all service packs & patches in place.
Deployed systems should have a range of applications that are installed.

Different groups of users should be able to be assigned different
application sets.
The end user should be able to rebuild their system (If authorised to).
Deployed systems should adhere to a company theme & configuration

policy.
Deployed systems should keep up to date with the latest OS patches.
If resources permit, the performance of simultaneous installs should be

investigated
Unfortunately, not all of the original target objectives were met. While a range
of applications were successfully installed to deployed systems, the range
was fixed - different groups of users did not have the ability to have different
sets of applications installed. This was unable to be implemented due to a
hard disk on the development network failing, which in turn caused delays in
the progress of the project until a replacement could be acquired. In addition
to this, the performance of simultaneous installations could not be
investigated, as it was not possible to obtain a large number of workstations
that could be rebuilt, although this was predicted as a potential constraint
when the objectives were originally specified.

20
5. Conclusions
From observing the progress of the project it can be clearly observed that
automating the deployment of workstations is beneficial to any business or
organisation that has a large number of workstations to support.
The project allows for a workstation with no operating system or data to be
plugged into the network and have the operating system, patches and
applications all automatically installed. The only user intervention that is
required is the initiation of the process. The deployment also contains
numerous configuration modifications, so that deployed clients can be
configured exactly to the companys policies and themes. A full client
deployment on the development network (using standard 1.5GHz machines)
takes around two hours to complete.
By implementing the solution demonstrated in the project, an organisation
could increase the efficiency of their technical support department as the
amount of time required for staff to deploy a client would dramatically drop,
and the time saved could be used elsewhere. Further to this, the system could
also be used for fixing more serious system errors, as it is likely that it would
be quicker to perform an automatic rebuild, rather than having a member of
the support staff spending time attempting to fix the error. The user of the
machine in question could also perform the rebuild, which potentially allows a
user to fix a serious fault without even having to contact the support
department.
The system requires very little specialist infrastructure in place, so can be
easily integrated into the majority of business class networks. Windows or
Linux based servers can be used, and the system does not require a
dedicated server it can be placed on an existing server with no problems. I
have even started to keep a copy on my laptop along with the boot CD, so
that I can rebuild friends computers easily.
After carrying out the work involved with the project I feel that I have a far
deeper understanding of the Windows operating system with regard to what
goes on under the bonnet. I feel that this is especially due to the fact that
typical methods used for system configuration couldnt be used in the project
(such as the usual point and click GUIs), which meant more complex
methods had to be investigated and used. I am also aware that my scripting
skills have been improved, as the deployments are heavily scripted so I was
constantly writing and editing them, in addition to this I also had to learn
regular expressions in order to produce the machine naming script that can be
found in Appendix C.

21
6. Recommendations for further work

The final system produced from the project is a fully working deployment
system that could be readily integrated into a network and start deploying
workstations immediately. If the project was to be continued further, there are
a number of aspects that could be further investigated:
6.1 Configuration based on MAC address

Clients currently all make use of a single configuration file, it is possible to
allocate certain clients different options based on the MAC address (this is a
unique hardware identification number). For example, clients with certain
MAC addresses may require their hard drives to be formatted differently to the
majority of clients.
6.2 Different application sets

Certain users may require a set of specialist applications, for example, users
in the accounting department will probably require the accounting packages.
These applications could then be grouped into sets for each group of users.
6.3 Keeping the server up-to-date

The deployment server must be manually kept up-to-date, by downloading
scripts from the unattended project website and then downloading patches
and updates installed by the scripts. This can be a tedious process, especially
if there are many different applications to check. This process could be
automated, so that the deployment server always has the most recent
patches and software available, it would also eliminate the possibility of
missing patches due to human error.
6.4 Configuration stored in a database

When the deployments are becoming quite complex, with different options for
certain workstations and different sets of applications for certain groups of
users, the configuration files can become quite large and unorganised. It
should be possible to store the entire configuration for each client, or group of
client machines in a SQL database. This could make configuring client
machines much easier, especially if a user friendly front-end was added to the
database.

22
References
[1] OS Market Share: Microsoft Stomps the Competition
[URL: http://www.windowsitpro.com/Article/ArticleID/40481/40481.html]
(Accessed: 09/11/05)
[2] Microsoft Lifecycle Information
[URL: http://support.microsoft.com/gp/lifeselect]
[3] Microsoft Deployment Tools Windows XP unattended installation
[URL: http://www.overclockers.com/tips1158]
(Accessed 17/11/05)
[4] MSFNs Unattended Windows
[URL: http://unattended.msfn.org]
(Accessed 17/11/05)
[5] The Unattended Project
[URL: http://unattended.sourceforge.net]
(Accessed: 19/11/05
[6] Microsoft Remote Installation Services
[URL: http://technet2.microsoft.com/WindowsServer/en/Library/
dc89bc1c-9df2-4fc3-ae7f-c46f1a8b41fa1033.mspx]
[7] tftpd32 home page
[URL: http://tftpd32.jounin.net]
(Accessed 01/12/05)
[8] Unattended Installation Tools and Settings
[URL:http://www.microsoft.com/resources/documentation/windowsServ
2003/all/techref/en-us/w2k3tr_unatt_tools.asp]
[9] Unattended The [_Meta] section
[URL: http://unattended.sourceforge.net/meta.php]
[10] How to integrate Windows XP SP2 into installation folder
[URL: http://support.microsoft.com/?kbid=900871]

23
Appendices
Appendix A Pxelinux configuration file
# isolinux/pxelinux configuration file
default localboot
timeout 20
prompt 1
label localboot
LOCALBOOT 0
label buildme
kernel bzImage
append initrd=initrd z_user=install z_pass=buildme z_path=//ntinstall/install

24
Appendix B Unattend.txt configuration file

[GuiUnattended]
TimeZone=85
OEMSkipRegional=1
OemSkipWelcome=1
AdminPassword=mosfet
[Unattended]
UnattendMode=DefaultHide
FileSystem=ConvertNTFS
ExtendOemPartition=1
OemSkipEula=Yes
OemPreinstall=Yes
UnattendSwitch=Yes
[UserData]
ProductKey=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
FullName="Network User"
OrgName="Squiggle UK"
ComputerName=*
[Identification]
JoinDomain=SQUIGGLE.ORG
DomainAdmin=SQUIGGLE.ORG\admin
DomainAdminPassword="mosfet"
[Components]
iis_common=On
iis_inetmgr=On
iis_www=On
iis_pwmgr=On
iis_doc=On
[Data]
AutoPartition=1
MsDosInitiated="0"
UnattendedInstall=Yes
[Display]
BitsPerPel=32
Xresolution=1024
YResolution=768
[TapiLocation]
CountryCode=44
Dialing=Tone
AreaCode=0
[LicenseFilePrintData]
AutoMode=PerServer
AutoUsers=5
25
[RegionalSettings]
LanguageGroup=1
Language=00000809
[Branding]
BrandIEUsingUnattended=Yes
[URL]
Home_Page=http://www.google.co.uk
Search_Page=http://www.google.co.uk
[Proxy]
Proxy_Enable=0
Use_Same_Proxy=1
[Networking]
InstallDefaultComponents=Yes
[NetOptionalComponents]
LPDSVC=0
[_meta]
top=full.bat
middle=""
local_admins=""
ntp_servers=""
edit_files=0
fdisk_lba=1
fdisk_cmds="fdisk /clear 1;fdisk /pri:4000;fdisk /activate:1"
fdisk_confirm=0
format_cmd="format /y /z:seriously /q /u /a /v: c:"
replace_mbr=1

26
Appendix C Machine naming script

use warnings;
use strict;
use Socket;
use Net::hostent;
my $default_computer_name = $u->{'UserData'}->{'ComputerName'};
my $ip_address = $u->{'_meta'}->{'ipaddr'};
my $host = gethostbyaddr (inet_aton ($ip_address));
if (!defined $host) {
$ip_address =~ m/^(([0-9]+).([0-9]+).([0-9]+).([0-9]+))/;
my $default_name = $default_computer_name . $5;
print "WARNING: Couldn't set computer name from hostname.
Computer name set to \"$default_name\"\n";
$u->{'UserData'}->{'ComputerName'} = $default_name;
}
else {
my $name = $host->name ();
$name =~ m/^(([A-Z]|[a-z]|[0-9]|-)+)(\..*)/;
my $hostname = $1;
print "Computer name set to \"$hostname\"\n";
$u->{'UserData'}->{'ComputerName'} = $hostname;
}
1;

27
Appendix D Example registry file

REGEDIT4
[HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Setup\UserOptions]
"DesktopShortcut"="no"
"QuickLaunchShortcut"="yes"
[HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Preferences]
"FirstRun"=dword:00000000
"StartInMediaGuide"=dword:00000001
"CDRecordMP3"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Player\Settings]
"EnableDVDUI"="Yes"
[HKEY_USERS\TempHive\Software\Microsoft\MediaPlayer\Setup\UserOptions]
"DesktopShortcut"="no"
"QuickLaunchShortcut"="yes"
[HKEY_USERS\TempHive\Software\Microsoft\MediaPlayer\Preferences]
"FirstRun"=dword:00000000
"StartInMediaGuide"=dword:00000001
"CDRecordMP3"=dword:00000001
[HKEY_USERS\TempHive\Software\Microsoft\MediaPlayer\Player\Settings]
"EnableDVDUI"="Yes"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsMediaPlayer]
"GroupPrivacyAcceptance"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\Settings\MP3Encodi
ng]
;"LowRate"=dword:0000dac0
;"MediumRate"=dword:0001f400
;"MediumHighRate"=dword:0003e800
;"HighRate"=dword:0004e200
"LowRate"=dword:0001f400
"MediumRate"=dword:0003e800
"HighRate"=dword:0004e200
[-HKEY_CLASSES_ROOT\.avi\ShellEx]
[-HKEY_CLASSES_ROOT\.mpg\ShellEx]
[-HKEY_CLASSES_ROOT\.mpe\ShellEx]
[-HKEY_CLASSES_ROOT\.mpeg\ShellEx]

28
Appendix E Network status icon script

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
FOR /F "TOKENS=1 DELIMS= " %%A IN ('REG QUERY
HKLM\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC108002BE10318}') DO (
SET TEMP1=%%A
SET TEMP2=!TEMP1:~99,38!
SET TEMP3=!TEMP2:~-1!
IF "!TEMP3!"=="}" (
IF NOT "!TEMP2!"=="{4D36E972-E325-11CE-BFC1-08002BE10318}" (
SET REGSTR1=HKLM\SYSTEM\CurrentControlSet\Control\Network\{4D36E972E325-11CE-BFC1-08002BE10318}\!TEMP2!\Connection
SET
REGSTR2=HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
\!TEMP2!
REG ADD !REGSTR1! /v ShowIcon /t REG_DWORD /d 1 /f
REG ADD !REGSTR2! /v IPAutoconfigurationEnabled /t REG_DWORD /d 0 /f
)
)
)

29
Appendix F Gant chart

30

GK Finalproj

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

GK Finalproj

Enviado por

Direitos autorais:

Formatos disponíveis

Department of Cybernetics & Virtual Systems

Final Year Project Report

Unattended workstation deployment

Supervised by David Forbes

Final Project Report

Final Project Report

Final Project Report

Final Project Report

3. Progress of the project

3.1.1 Choosing the version of the operating system

31st Dec 2002

31st Dec 2006

31st Dec 2011

31st Mar 2000

30th Jun 2005

30th Jun 2010

29th Jul 1999

30th Jun 2003

30th Jun 2004

Figure 1 Windows Lifecycle Support

Final Project Report

3.2 Applications and utilities to deploy

Microsoft Office 2003 Professional

3.3 Methods of deployment

Final Project Report

Runs on Windows or Linux servers

Requires Microsoft domain infrastructure

Script based installation

Image based installation

Easy to integrate new patches

Harder to integrate new patches

Slower installation (~=2 hours)

3.4 Infrastructure preparation

Figure 3 The install share

3.4.1 Adding the operating system

3.4.2 Booting from the network

Final Project Report

Figure 4 The network boot process

3.5 Specifying installation options

3.5.1 Windows setup options

3.5.2 Unattended script options

3.5.3 Naming the client machine

Final Project Report

3.6 Updating Windows

3.6.1 Slipstreaming the service pack

3.6.2 Adding patches and updates

appending /passive /n /norestart to the command, these command line

3.7 Adding applications

3.7.1 The install script

3.7.2 Installing applications

Figure 5 The Windows installer command line arguments

Final Project Report

Should obtaining a working set of command line argument be unachievable,

3.8 Configuration modifications

(GPOs). The deployment system being developed is intended for any

3.8.1 Updating the start menu and desktop

3.8.2 Registry modifications

publish information on where certain options can be located in the registry - it

3.8.3 Other modifications

3.8.4 Applying to the default user

Final Project Report

Allow a popular workplace operating system to be deployed without the