Standard Windows Deployment is based on the Active Directory and software distribution through the Microsoft Installer service. Unfortunately, this is an imperfect world, so fine tuning scripts need to be run for fully automated installation and management of Windows hosts. Microsoft did see that and provided a mechanism to run scripts at boot time or at logon time. Managing these scripts is however rather tedious since they are specified in a rather obscure location in the GUI, so we developed our own text-configuration based tool to manage these scripts: bootmgr.

The boot process is divided in features, that is in boot scripts a-la init.d. A file called BOOT configures what feature gets installed on which host. The features are installed in directories on a Unix server, one per feature, with a file called META in them to specify when and how the feature should be applied.

The BOOT file looks as follows:

repository = //winpack/pack/boot

*** features ***

isg_special     OU:isg.ee
iexplorer55     -HOST:kazago,ALL
kazago_fix      HOST:kazago

repository specifies where the features are stored, that directory must be available to clients.

The features section specifies what feature has to be run on which host. The section contains a table, where the first column is the name of the feature and the second contains a list of host specifications separated by commas (without spaces). The host specifications can be:

'HOST:xxx'

run that feature on host xxx

'OU:xxx'

run that feature on hosts that are in the Active Directory OU xxx (the syntax is ou1.ou2.ou3.etc.)

'ALL'

run that feature on all hosts

Each host specification can be preceded by a dash, in which case if the host matches, the feature won't be executed (the specifications are processed left to right).

Each feature is contained in a directory that contains files needed by that feature and a META file to specify what bootmgr should do. The META file looks as follows:

description = Hotfix to run more applications
maintainer  = mo
version     = 2
type        = once

*** command ***

appupd.exe /Q

The following variables can be used:

description

Short description of the feature. Mandatory.

maintainer

User-name or marker of the maintainer. Mandatory.

version

Version number of the feature. If type is once or last then if the feature was already run but with a version number that is smaller, then the script will be run again on that machine. Defaults to '1'. Optional.

type

Type of feature. If once, then run only once on the machine, if always, run on every boot and if last run only once by also stop further processing of features (this is needed if the feature does a reboot, since bootmgr can't start anymore processes if the machine is rebooting). Defaults to 'once'. Optional.

The command sections contains the commands that bootmgr should execute. bootmgr will first enter the feature directory, write these commands in a .bat file and execute it.

bootmgr will write in %SYSTEMDRIVE%\ISG\bootmgr\log\bootmgr.log a log of what was executed, including the output of the batch files. It will also write in %SYSTEMDRIVE%\ISG\bootmgr.db which feature and what version of the feature was run when, so that it can check if a runonce script must be executed.

If the file %SYSTEMDRIVE%\reboot is present, bootmgr will not execute the boot features but will instead reboot the machine by executing (Shutdown.exe is available from the Windows 2000 Resource Kit):

%SystemRoot%\Shutdown.exe /L /R /T:2 /y /C

If the file %SYSTEMDRIVE%\unconfig is present, bootmgr will immediately reset it's database of installed features, remove the 'unconfig' file and quit (or reboot if %SYSTEMDRIVE%\reboot is present).

A problem that we encountered with this solution are the forking (background) applications that do a reboot or on which other features depend. Such applications exit immediately and run in the background, and it is for that reason impossible for bootmgr to know when the execution of a feature is really finished. It can be a real problem if for example a background installer does an automatic reboot: it may do so when another feature is being executed and thus cause bad things to happen.

We solved that problem with two techniques: we added the feature-type last that makes bootmgr stop processing further features (which is what you want when a feature does a reboot) and we have written a very short script called waitproc.pl that waits for a forked application to finish (it looks at the list of processes using tlist.exe from the resource kit and finishes when the regular expression given on the command line doesn't match any command).