Re: Changing Hardware Platform
From: Jeff Middleton [SBS-MVP] (jeff_at_cfisolutions.com)
Date: 05/18/04
- Next message: Phil S.: "Re: SBS 2000/Exchange2000 and Internet Mail"
- Previous message: Jimmy: "SBS 2003 client disk"
- In reply to: root: "Re: Changing Hardware Platform"
- Next in thread: root: "Re: Changing Hardware Platform"
- Reply: root: "Re: Changing Hardware Platform"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 17 May 2004 22:08:25 -0500
> > only about 3 common HALs in the Windows OS library....there are
literally
> > dozens of EIDE controllers...perhaps even a dozen-dozen. Your chances of
> the
> > move failing because of a 7b Stop error is really high.
>
> Has that changed significantly from XP to SBS2003? There was much FUD
> around about similar things in XP and that turns out to be not so. If the
> HALs are the same then the OS figures out what's needed IDE wise and does
> the change transparently in most cases in XP. If one carefully looks at
the
> driver structure then one finds that there are just a few IDE drivers.
The
> number of possible IDE controllers isn't relevant since that gets detected
> on the fly.
>
This hasn't changed at all. In fact, I'd say it's getting worse for an odd
reason. Used to be in the late 1990s and early 2000 time frame, most
motherboards were still going to be compliant to a baseline IDE driver that
was generic. This is what we remember from the grand days of Win9x.
With release of Windows 2000, the floodgates openned and the number of
permutations of EIDE drivers exploded. Now you have multiples of chipsets
and EIDE controllers combined.
The main point though that you are asking about is a common misconception.
You can't expect PnP to solve your boot controller issue. Windows doesn't
use PnP to detect the primary boot controller. That device has to pre-exist
in the registry, the driver has to pre-exist in the 32-bit drivers cache,
the driver itself needs to be set to start at boot....not automatic...and
that means that the driver is effectively preinstalled, not detected. It's
only after the boot controller has been located that the PnP kicks in, so as
that case would lead us to, you can't make Windows boot from a controller it
hasn't previously been through a boot cycle without either manually updating
the registry and the driver cache, or else by running Windows Setup again to
let it do the job for you. Windows Setup requires the typical 45 minutes to
install, same as a scratch install, only difference is that you preserve the
balance of the system configuration.
The method I outlined works 19 out of 20 times. The times that it doesn't
work are going to be due to pretty odd conditions, for instance, a boot
controller that requires boot.ini entries that are SCSI(x), rather than
multi(x)...which implies that the NTBOOTDD.SYS is a custom file, etc. That
can be overcome by a custom boot floppy, but on the whole the method I
described makes that somewhat less of a risk to do.
To put a finer point on it, at the end of 2001, I had been working on a
project in which it was my desire to produce a single drive image with
Windows 2000 Pro on it that would actually boot every Intel (brand)
motherboard I had sold in the past 4 yrs. I got the image requirements done
to two images. One for non-ACPI HAL, one for ACPI HAL. About that time that
XP shipped in 2002 (9 mos later), I was back up to 3 images for XP for
various reasons, mainly that I couldn't get drivers preinstalled for each
HAL and device driver without actually moving an reinstalling drivers from
scratch by rerunning setup. There was about a 1yr delay from Intel releasing
the utility that preloaded the Intel EIDE drivers and chipset drivers.
I can now do it with 2 XP images (last time I looked at it), but it's a
moving target now because the patching update requirements have lead me to
no longer care as much about maintaining a single image as much as
preserving the ability to install without prompts....which XP does better
than W2K did.
As for Server 2003, I really haven't even started into replacing my servers
that aren't SBS yet....MS has managed to total hose the licensing incentives
for upgrading servers from W2K to W2K3. Therefore, I'm not really imaging
Server 2003 at the moment much. That said, I do have a couple of sites that
I can push a single drive image to any one of a dozen different servers that
are a range of PIII, Dual PIII, Dual Xeon motherboards. On that basis, I'm
less concerned with having an image from the previous night, as much as I
want any image at all that allows me to boot the machine again, rename it,
then restore from tape of the last night. Recovery time is about 30-45
minutes in a lab setting, closer to 90 minutes in production situation. I
actually used the same tools as a technique to add a 4th TS apps server to a
site in under 2hrs from a bare metal configuration. That included the time
to go from PXE boot, push the image, rename the server, join the domain
manually, then manually install Office and a couple of applications not in
the image, then reconfirm group policy configurations that are server
specific in path naming. It was a case of an emergency deployment that
worked pretty well.
"root" <postmaster@buchanangc.com> wrote in message
news:emq2qCHPEHA.3708@TK2MSFTNGP10.phx.gbl...
>
> "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
> news:ewEAoZGPEHA.736@tk2msftngp13.phx.gbl...
> > In addition to Root's comments....
> >
> > An EIDE drive is a bad choice for lifting a complete installation
between
> > different server hardware. That's because if you plan to use the onboard
> > EIDE at the target server, you will find out eventually that while there
> are
> > only about 3 common HALs in the Windows OS library....there are
literally
> > dozens of EIDE controllers...perhaps even a dozen-dozen. Your chances of
> the
> > move failing because of a 7b Stop error is really high.
>
> Has that changed significantly from XP to SBS2003? There was much FUD
> around about similar things in XP and that turns out to be not so. If the
> HALs are the same then the OS figures out what's needed IDE wise and does
> the change transparently in most cases in XP. If one carefully looks at
the
> driver structure then one finds that there are just a few IDE drivers.
The
> number of possible IDE controllers isn't relevant since that gets detected
> on the fly.
>
> > You could be better
> > off either using a PCI EIDE card or a PCI SCSI card and drive. If you
have
> > compatible SCSI controller planned for the other server (or SCSI on both
> > motherboards that you plan to use), you may well find that the drive
> mounts
> > without a problem, but I would be very careful about assuming that a
RAID
> > can be lifted that way unless the controller, drives and Hotswap Chassis
> > move as an entire set, including the internal cable.
> >
> > As was suggested, make an image of your system drive to do the test
with.
> >
> > If you are a dealer and want to do this on a regular basis, do yourself
a
> > favor and pick PCI based combination of controller and drive that you
can
> > use. Preinstall the controller in the source system with your "Travel"
> drive
> > connected to it. Do a full boot cycle and install the drivers for the
> card.
> > Shutdown, image the drives (or do a mirror mate and split if you have
that
> > kind of time an no imaging software). Shutdown and take the production
> > drives offline.
> >
> >
> > Disconnect the NIC cables. (you don't want any authentications, email or
> > other traffic flowing while you do this test.) Attempt to boot the
source
> > machine from the Travel drive. If it succeeds, you are ready to try it
on
> > the target server.
> >
> > Disconnect the NIC cables on the target server, same reason as before.
> > Install the PCI card and the travel drive to the target server. If you
can
> > boot this target machine with the Travel drive, you now know that the
> system
> > installation is going to work without modifications. If the boot fails,
> > depending upon the error message, you are either going to need to change
> the
> > HAL indicated on -this- drive's system installation by moving it back to
> the
> > source server and doing a HAL change before a shutdown.....or possibly
you
> > have an issue with the boot order of the boot devices on the target
> machine.
> > There are other explanations, but these are the most likely.
> >
> >
> >
> >
> > "root" <postmaster@buchanangc.com> wrote in message
> > news:uwngaOJOEHA.4036@TK2MSFTNGP12.phx.gbl...
> > >
> > > "Craig Schaefer" <anonymous@discussions.microsoft.com> wrote in
message
> > > news:c04001c43826$7ed92810$a301280a@phx.gbl...
> > > >
> > > > In the past on this Newsgroup I have seen links to site
> > > > where there is a procedure for moving an SBS Server
> > > > installation to new hardware that has a different HAL. I
> > > > want to physically move an IDE drive to a different
> > > > computer.
> > >
> > > A different HAL and moving an IDE drive aren't the same thing. What's
> the
> > > mobo and CPU on both systems? It might just outright work. If you
can
> > > image the drive for safe keeping then just try it.
> > >
> > > > Is someone able to point me in that direction ?
> > > >
> > > > Thank You
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Phil S.: "Re: SBS 2000/Exchange2000 and Internet Mail"
- Previous message: Jimmy: "SBS 2003 client disk"
- In reply to: root: "Re: Changing Hardware Platform"
- Next in thread: root: "Re: Changing Hardware Platform"
- Reply: root: "Re: Changing Hardware Platform"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
