[ale] OT: NT/XP/2K/2K3 Disk Imaging

Brian MacLeod nym.bnm at gmail.com
Wed Sep 21 10:04:57 EDT 2005


Hadn't heard of this, need to check this out. Thanks Keith!

bnm

On 9/21/05, Keith.Watson at gtri.gatech.edu <Keith.Watson at gtri.gatech.edu>
wrote:
>
> > -----Original Message-----
> > From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
> Jeff
> > Hubbs
> > Sent: Wednesday, September 21, 2005 05:40
> > To: ale at ale.org
> > Subject: [ale] OT: NT/XP/2K/2K3 Disk Imaging
> >
> > Back in my age of pre-enlightement, the rule of thumb was that disk
> > images made from one NT (or subsequent derivative) machine could be
> > installed on outwardly identical machines, but doing so was
> discouraged
> > because NT made installation decisions based on the hardware it saw at
> > install time and that small running changes (e.g., different rev level
> > within a mobo chipset) between outwardly identical machines would be
> > detected at install time and different binaries would go on disk, so
> as
> > to result in a deviation between the OS installed on an image-created
> > machine and the OS that would be there had it been installed on the
> > exact same unit. As a result, you could wind up with a machine that's
> > crash-happy and you'd never be able to figure out why.
> >
> > Does anyone know if this is still the case with current releases of
> > Windows OSses?
> >
> > As an aside, supposedly, Linux wasn't *as* susceptable to this because
> > you could make allowances at kernel-config-time and beyond that, the
> > kernel and modules would decide what they saw when they were first
> > invoked, particularly at boot time. In other words, if you compiled an
> > everything-but-the-kitchen-sink kernel and booted to it and/or started
> > the modules, they would sense rev-level issues and switch themselves
> > appropriately (such as the CMD640 IDE bug).
> >
> > As other people have, I ask here off-topically because of the general
> > sharp-cookie quotient.
> >
> > Jeff
>
> Jeff,
>
> I've managed to get Windows 2000, XP, 2003 images that work across
> multiple machines with different hardware configurations although it can
> be a bit of a challenge at times. In theory if the drive controller or
> ASPI configuration are different then it won't work. In practice there
> are ways to get around the drive controller problem and to add new
> controllers to the image. I've never found a good way around the ASPI
> problem but I don't encounter the problem much as most modern
> motherboards support a standard version of ASPI. Another issue is
> installing a multi processor image on a single processor machine. The
> solution is the install it a single processor image and then upgrade to
> multiprocessor where needed.
>
> There is a new product I just heard about, but have not tried, called
> Universal Imaging Utility that claims to solve this problem.
>
> http://www.binaryresearch.net/UIU.htm
>
> keith
>
>
> --
>
> Keith R. Watson GTRI/ISD
> Systems Support Specialist III Georgia Tech Research Institute
> keith.watson at gtri.gatech.edu Atlanta, GA 30332-0816
> 404-894-0836
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>
-------------- next part --------------
An HTML attachment was scrubbed...




More information about the Ale mailing list