GK-Finalproj

Department of Cybernetics & Virtual Systems

Final Year Project ReportFor the degree of

Computer Systems Administration

By

Geoff Kendal

Unattended workstation deployment

Supervised by David Forbes2006

Final Project Report 1Geoff 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...................................................................................................52. Project resources.........................................................................................53. Progress of the project.................................................................................6

3.1 Investigation of operating systems..........................................................63.1.1 Choosing the version of the operating system.................................6

3.2 Applications and utilities to deploy..........................................................73.3 Methods of deployment...........................................................................73.4 Infrastructure preparation........................................................................8

3.4.1 Adding the operating system............................................................93.4.2 Booting from the network.................................................................9

3.5 Specifying installation options...............................................................103.5.1 Windows setup options..................................................................103.5.2 Unattended script options...............................................................113.5.3 Naming the client machine.............................................................11

3.6 Updating Windows................................................................................123.6.1 Slipstreaming the service pack.......................................................123.6.2 Adding patches and updates..........................................................12

3.7 Adding applications...............................................................................133.7.1 The install script.............................................................................133.7.2 Installing applications.....................................................................13

3.8 Configuration modifications...................................................................153.8.1 Updating the start menu and desktop............................................163.8.2 Registry modifications....................................................................173.8.3 Other modifications........................................................................183.8.4 Applying to the default user............................................................18

4. Project management..................................................................................205. Conclusions................................................................................................216. Recommendations for further work............................................................22

6.1 Configuration based on MAC address..................................................226.2 Different application sets.......................................................................226.3 Keeping the server up-to-date..............................................................226.4 Configuration stored in a database.......................................................22

References.....................................................................................................23Appendices.....................................................................................................24

Appendix A – Pxelinux configuration file.....................................................24Appendix B – Unattend.txt configuration file...............................................25Appendix C – Machine naming script.........................................................27Appendix D – Example registry file.............................................................28Appendix E – Network status icon script.....................................................29Appendix 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 PC’s. 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 Microsoft’s business grade operating systems (Windows 95/98 etc. are designed for home, not business use).

Product Name Release Date Main SupportEnd Date

Extended SupportEnd 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 Microsoft’s 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 Microsoft’s ‘Remote Installation Services’ [6].

The main differences between these solutions are outlined in the following table (Figure 2):

Unattended project Microsoft RIS


Open source

Runs on Windows or Linux servers

Script based installation

Easy to integrate new patches

Slower installation (~=2 hours)

Commercial software

Requires Microsoft domain infrastructure

Image based installation

Harder to integrate new patches

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 to the ‘install’ share on the


Figure 3 – The install share

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 user’s 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 unattended-linuxboot.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


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


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


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.


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 vendor’s website usually has a comprehensive guide of command line arguments that can be used, even if the installer itself won’t 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.

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 isn’t 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 (GPO’s). 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 aren’t 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 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 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 can’t 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 isn’t 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 user’s 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 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.


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.


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 company’s 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 friend’s 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 couldn’t be used in the project (such as the usual point and click GUI’s), 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.


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.


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](Accessed: 11/11/05)

[3] Microsoft Deployment Tools – Windows XP unattended installation[URL: http://www.overclockers.com/tips1158](Accessed 17/11/05)

[4] MSFN’s 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](Accessed: 23/11/05)

[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/windowsServ2003/all/techref/en-us/w2k3tr_unatt_tools.asp](Accessed: 07/12/05)

[9] Unattended – The [_Meta] section[URL: http://unattended.sourceforge.net/meta.php](Accessed: 09/12/05)

[10] How to integrate Windows XP SP2 into installation folder[URL: http://support.microsoft.com/?kbid=900871](Accessed: 22/11/05)


http://support.microsoft.com/?kbid=900871

http://unattended.sourceforge.net/meta.php

http://www.microsoft.com/resources/documentation/windowsServ%0D2003/all/techref/en-us/w2k3tr_unatt_tools.asp

http://www.microsoft.com/resources/documentation/windowsServ%0D2003/all/techref/en-us/w2k3tr_unatt_tools.asp

http://tftpd32.jounin.net/

http://technet2.microsoft.com/WindowsServer/en/Library/%0Ddc89bc1c-9df2-4fc3-ae7f-c46f1a8b41fa1033.mspx

http://technet2.microsoft.com/WindowsServer/en/Library/%0Ddc89bc1c-9df2-4fc3-ae7f-c46f1a8b41fa1033.mspx

http://unattended.sourceforge.net/

http://unattended.msfn.org/

http://www.overclockers.com/tips1158

http://support.microsoft.com/gp/lifeselect

http://www.windowsitpro.com/Article/ArticleID/40481/40481.html

Appendices

Appendix A – Pxelinux configuration file

# isolinux/pxelinux configuration file

default localboottimeout 20

prompt 1

label localboot LOCALBOOT 0

label buildme kernel bzImage append initrd=initrd z_user=install z_pass=buildme z_path=//ntinstall/install


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


[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


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;


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]"AcceptedPrivacyStatement"=dword:00000001"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]"AcceptedPrivacyStatement"=dword:00000001"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\MP3Encoding];"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]


Appendix E – Network status icon script

@ECHO OFFSETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION

FOR /F "TOKENS=1 DELIMS= " %%A IN ('REG QUERY HKLM\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}') DO (

SET TEMP1=%%ASET 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\{4D36E972-E325-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

)

)

)


Appendix F – Gant chart
