Archived from groups: 24hoursupport.helpdesk,alt.os.windows-xp,microsoft.public.windowsxp.general,microsoft.public.windowsxp.hardware (
More info?)
"Shenan Stanley" <news_helper@hushmail.com> wrote in message
news:u78UaqbLEHA.1644@TK2MSFTNGP09.phx.gbl...
> Answers inline...
>
> jim wrote:
> > I'd like to ask some questions about replacing/changing a mobo in an
> > XP pro system. I've done some research on this issue and have come to
> > the following conclusions.
> >
> > XP is not quite as Plug & Play as 98[SE] was in this regard. One can
> > not just take the OS HD and put it in another box and expect it to
> > boot and re-find everything and install all the appropriate drivers
> > etc. like it would in 98SE.
>
> Yes - XP is not as "Ghost/Clone friendly" as its predecessors. You could
> take all Windows OS's before it (Windows 95, 98, ME, NT, 2000) and usually
> put it on a different set of hardware and with minimal muss/fuss, you
could
> get it going. You could even then make an image with the additional
> drivers/HAL information added and now the image would function on multiple
> machines without a problem. With the advent of WIndows XP, this
simplicity
> and grace went away,
Some of it went away but apparently alot of the same functionality is still
there in XP as I described in my opening post.
> a more forceful approach (or actually using tools like
> sysprep) became necessary in order to clone the software to another set of
> hardware than that it was originally installed upon.
>
> > The limitations appear to be in two areas. The first is the HAL
> > which is a function of the CPU and number thereof and
> > presence/absence of ACPI mobo BIOS. The second is the HD drivers.
> >
> > I've found all sorts of site/articles regarding how to do this and
> > fix these issues for the mobo ATA controller case. Other HD cases
> > seem to be tractable using the F6 install drivers(SCSI technique).
> > One that seems to be similar to many others regarding the mobo ATA HD
> > issue is: www.mostlycreativeworkshop.com/article11.html
> >
> > My conclusion is that one should make the registry and file additions
> > on any XP system so that failure recovery on new hardware is more
> > convenient at a later time. Am I missing something here or is that
> > about right.
>
> The concerns with your conclusion is that you know when the failure is
going
> to occur and what hardware you will be moving it to before that failure
> occurs.
I don't follow. No precognition is necessary regarding time or target.
> Not only that, this is Windows XP - not that important of an OS in
> the scheme of things - certainly not a server-level catastrophic failure
> event. If it is, then you have not thought out your network/user
> environment well, or in the case of a single-user environment, you were
dumb
> enough not to make backups.
Huh? You gone off on some magical mystery tour outside the scope on my post
and intentions. Thius is not a backup issue.
> Assuming this has nothing to do with JUST failure recovery,
This has everything to do with FAST failure recovery and also just hardware
upgrades unassociated with any failure.
> but just ease of
> movement to a new set of hardware or even, as is done in many university
> type environments, ghosting to diverse lab machines - then some of your
> assumptions are correct.
Right.
> I know of a group that uses one image (clone) to
> ghost several different sets of hardware (vastly different) by ripping out
a
> large section of the registry and replacing that chunk with the proper
chunk
> before the first GUI boot after applying a cloned image.
Right there are a number of places on the web describing such registry mods.
> XP fought them
> tooth and nail on doing the older style they were used to with Windows
2000
> and before of just adding additional hardware information so that
> application to another set of hardware components were built in - it
seemed
> to clean itself up in other words - the new drivers needed took out the
old
> drivers instead of just being added - thus their new methodology.
XP is removing stuff? Can you cite any sources on that, please. That's
one of the issue I'm actively researching: Why not put all that stuff in
the registry up front in preparationfor any later potential HW change? The
question is will XP let it stay there gracefully.
> > The second issue is that HAL. If the old and new systems are single
> > CPU ACPI mobos then everything works. It makes no difference is one
> > is a VIA chipset and Athlon and the other an Intel chipset and an
> > Intel CPU. Do I have this right so far?
>
> No. You are not. Try it. Get two systems, identical in everything but
> chipset and swap hard drives. I don't mean two different versions of a
VIA
> chipset or something lame, but one Intel, one via. My experience says
> Windows XP will freak - to put it in layman's terms.
Actually I am right in at least some cases. The question is how right am I
across many different cases. Where do any problems arise. See the post
using the same subject yesterday in microsoft.public.windowsxp.general from
Gary R. :
"While one person's experience is hardly something to depend on, I replaced
a
failed mobo in a Gateway a couple of months ago, going from a P4/Intel
system to Athlon/Via, fully expecting to have to reinstall with a new copy
of XP (because the original was a Gateway OEM.)
To my surprise, the hardware was recognized and installed just as it usually
is in ME or 98. Once I installed all the Via drivers, everything worked
absolutely without a hitch. "
This DOES WORK the issue is the HAL and the IDE[disk] drivers. If you get
the HAL right and the disk is readable then things work. The question is
how robust is the "DOES WORK"?
> > If one is going from a single CPU case to a new P4 supporting HT then
> > one must force in a new HAL for multiprocessor ACPI. Apparently that
> > can be done in Recovery console or by putting the HD in another
> > system where files may be manipulated before attempting a boot on the
> > new mobo. Right so far?
>
> This is true. With some manipulation (as mentioned above earlier, before
> booting in the new system) you can accomplishing some pretty cool things.
>
> > Are the above the only two issues? Will all the other gadgets and
> > chipsets etc. be redetected and appropriate drivers installed? Will
> > one be able to boot and move forward in most all cases if the above
> > two issues are dealt with?
>
> I think I covered this above. YES, it is possible to do what you are
> suggesting in some ways. Practical, no - possible, yes. If your purpose
is
> disaster recovery, as implied - not only is it impractical, but impossible
> to predict when the failure will occur and what hardware (chipset, drives,
> video cards, network cards, etc) will be in the replacement system, or if
> the data on the drive will even be in a state to do this recovery.
Well no. All of my postings on this issue have obviously been predicated
on the assumption that the HW failure was a non-HD and non-HD corrupting
failure. If there was a HD or HD corrupting failure then one must go to a
backup. Some of us were smart enough to figure out that the best backups
are full HD image backups(aka Ghost etc.). So if you want to view this
thread from another angle then re-title if "How to quickly recover from any
HW failure using your HD image backup"
> You state "My conclusion is that one should make the registry and file
> additions on any XP system so that failure recovery on new hardware is
more
> convenient at a later time." To me, that is the true failure of this
whole
> discussion. If your conclusion had been "My conclusion is that one could
> make the registry and file removals/changes on an XP system so that
cloning
> on new hardware is possible." Then you would have me agreeing 100% - but
> you said recovery.
As I've already describe the two issues are the same issue.
> If you are using XP as a server or even as a personal
> system and something fails - I don't care if it is as simple as the
> motherboard and all data is recoverable - it is easier, faster and more
> practical in the worse case scenario (or just simple fact you consider
> hardware failure an opportunity to upgrade power/speed) of all
hardware/not
> data replacement to do a repair installation and move on with life.
Simply wrong as described above.
> You
> cannot predict in a failure scenario what hardware you will be moving to.
Don't need to.
> And if it is not a failure scenario - again - yes - I agree, there are
> things you can do to move without doing an actual repair installation, but
> unless doing it on a grander scale than the casual home user - it seems
like
> a worthless endeavor...
Huh? Catch up.
> UNLESS, and here is my other conclusion (possible scenario actually) from
> your persistence in this matter - you are trying to come up with some
> programmatic way of transferring the system so you can create a product to
> do exactly what you are discussing here - in which case you have made a
bad
> business decision in discussing it here, as people who are doing it now
may
> decide, "Not only is it possible and I am doing it now, but I can create a
> product and get it to market now and this guy made me realize it." -- They
> may thank you...
>
> Otherwise, in my years of cloning thousands of systems every 3-5 months
with
> 100+ applications installed upon each system working together and
thousands
> of roaming profile users all with different needs/wants - it seems only
> practical and worthwhile to someone like me - who would have figured out
> other methods are usually faster, making sure that the users data is never
> stored on the local machine anyway and if it is, tough luck, they should
> back it up.
if2909v48vmo2riifeqo0euiallqdmmn5@4ax.com...
Facebook
Twitter
Instagram