There are certain inherent problems with image duplicating for NT box
propagation. While having identical hardware helps immensely with avoiding
wierd and unusual problems, this is no guarantee. I've had identical
machines with very small chip revisions in devices as insignificant as
IOMega Zip drives cause BAD systemic problems when machines are duplicated
with copying programs such as Ghost.

A year two Taylor University network administrators, Aaron Brooks and Joel
Martin, created a linux boot disk system which can build any of our lab 
in about an hour and a half. The build process is a true NT install complete 
with 75+ applications which serve the CSS and Science divisions which we 
service. Did I mention that these machines dual boot to linux too and that is 
part of the build? The components are the following:

* A boot disk containing only a DHCP kernel-autoconfig NFS root kernel
* an NFS server with the NT i386 image and a base unattend.txt file. This
NFS server doesn't necessarily need to be a Linux box. This could be an NT
box running WarNFS or something like that if someone wanted to do that.
* a series of perl scripts which, given the machine name and hardware
probe information, customize the unattend.txt file
* a perl script which sucessively launch installation of apps after the
initial NT build is complete
* a perl script which installs diffs from Microsoft's SysDiff program (we
have really augmented this process if you are rightfully having doubts
about the standard SysDiff process)
* a script which does DLL and other file conflict and version resolution
* a SaMBa server which houses the diffs of the applications
* a series of ScriptIt files to install apps that don't SysDiff well (MS 
IE 5, MS Publisher 2000, MS NT SP 5 (6? not yet baby, not yet), sense a
theme. Typically these are things which perform OS upgrades (are apps
supposed to do that>??))
* Perl and  ActiveState Perl run the system from the Linux and NT sides

This is the only way that our network is managable. Our hardware is
totally heterogeneous, our custom configurations is broad, we need some
machines to run all apps on the network, some machines need to run some
off of the network and others that need all apps to be local. The system
is entirely customizable. A full, proper installation is done, dual
booting linux, in about 1-2 hours depending on config. (It used to be
under an hour before we started installing MetroWerks Codewarrior and
Visual Studio locally for performance reasons.)

Things this system doesn't do right now or could do better:

* Run with little configuration for a novice NT/UN*X admin. This currently
requires some know-how. It turns knowledge into power, configuration, and
most importantly freed time. (Oh, yeah, and stability -- we control the
DLL versions... this really helps out a lot (see MSDN newsletter Jan/Feb
2000, article "The End DLL Hell")
* Resolve conficts of registry keys. This is a very rare occurance since
the registry, at least in some manner, compartmentalizes apps'
information. Generally we have to hand manipulate any shared path keys in
the diff. Rare but it would be nice to have done automatically -- does
require some level of programmable smarts.
* One word: Multicast -- unicast hurts us the most for performance. The
performance is still outstanding considering the sheer volume of apps that
we run but if you need a machine redone in 1/2 an hour this project
currently isn't for you.

This project is not necessarily tied to SaMBa but if you really want to
have an automated network you will want a Linux/UN*X box at the back end
and SaMBa makes this all fly smoothly.

Right now JACAL is really only in a usable state for TU. We have had the
idea of releseing this all along and have sculpted this to be modular and
platform independant. (Yes, in theory this could also do Win95/98/2000,
BeOS, or anything else.)

We'd like to see this tool work for other people too. It as made our lives
much better here. (It takes 25+ hours straight to install all of our apps
by hand. Image copying would never work on our diverse hardware.)