moving live Windows2000 to another disk

[Frantisek Rysanek]

Dear fellow usenetters,

I've developed a deterministic procedure of how to
move a live Windows 2000 install to a different disk
drive on a different controller (different driver,
even externally installed).
It took me a while to figure out and I'd like to share
a summary with others.

There are occasions when you'd like to move a working
Windows install onto a new hardware setup - without
reinstalling from scratch and without repairing the
setup from an install CD, which may break applications
that are already installed, service packs applied etc.

It's not a simple as copying the files, even ghosting
the partition won't do.


Let's have a machine with a single IDE disk drive,
with Windows 2000 installed on it.

The "NT boot loader" menu is based on a file
called C:\boot.ini. This Menu currently contains
a single entry - boot.ini says something like this:

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional"

Using regedit.exe, check the disk volumes mounted - they're
listed at HKLM\SYSTEM\MountedDevices\*
Your only hard drive should be listed as something like
"\DosDevices\C:"

Consequently, the system boot goes like this:

boot boot.ini registry files mounts
-----------------------------------------------------------
bootsect0 -> rdisk0/part1 -> rdisk0/part1 -> disk0=C

Now suppose you install an exotic SCSI controller with a disk
drive attached to it (or a RAID controller of some kind, 3ware
for instance, with an array created on it). Configure the BIOSes
such that the original IDE drive is the first in BIOS order.
After you install the hardware, launch W2k from the original
C drive and install the drivers for the new disk controller
(the driver is not a standard part of the system).

Now the system contains two disk drives on two different
controllers: the original IDE "C" drive (containing Windows),
and the new drive on the additional controller (still empty).

On the original C drive, add a line to boot.ini:
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional"
multi(0)disk(0)rdisk(1)partition(1)\WINNT="Microsoft Windows 2000 Professional"

The "multi(0)" root is used for Enhanced BIOS access (via int13) - there's
perhaps never a higher-numbered multi() device. Disk() is unused with
int13 access - always a zero. Rdisk() is the drive's ordinal number
and partition() is the partition's ordinal number. All the numbers are
zero-based, except for partition which is one-based.

Alternatively, instead of the multi() root, NT4 could also use a scsi() root
with slightly different semantics and with a dedicated driver stored in
C:\ntbootdd.sys (a renamed driver file from the manufacturer's driver
disk). W2k doesn't seem to be dependent on this (the default IDE driver
is not stored in ntbootdd.sys anymore). The point is that with
the Int13 BIOS call, only the first 8 GB of the disk are accessible,
whereas via the scsi() root and native drivers, the bootloader can
reach anywhere on a huge disk and is only limited by the SCSI and
NTFS limits, which are beyond todays hardware...

Now clone the disks - use your favourite disk copy tool,
whatever it is (Norton/Symantec ghost, standard unix dd
or whatever).

We already have the W2k driver installed - without it, the
system would return an INACCESSIBLE_BOOT_DRIVE blue
screen during second stage of loading from the new drive.

Hence, now the branching boot sequence looks like this:

boot boot.ini registry files mounts
-----------------------------------------------------------
bootsect0 -> rdisk0/part1 -> rdisk0/part1 -> disk0=C,disk1=D
rdisk1/part1 -> rdisk1/part1 -> disk0=C,disk1=D

You can't remove the first disk yet. If you did, the boot sequence
would look like this:

boot boot.ini registry files mounts
-----------------------------------------------------------
bootsect1 -> rdisk1/part1 -> rdisk1/part1 -> disk0=C,disk1=D

This way, W2k stop loading just after the default blue "desktop"
is displayed. W2k actually complain about the swap file being
inaccessible - and either lock up with only the mouse moving
across the clear heavenly blue of the desktop, or repeat the
"swapfile inaccessible" message in a loop. Clearly, this way
Windows can't access the C drive.

Drive letters' mapping is set in the registry and can be changed
by Regedit.exe - which only works from graphical Windows environment.

Hence, still with both two drives in the system, boot Windows from the
_SECOND_ boot profile. This causes Windows to load from the new drive,
including the registry files - although most of the user-space
programs run by absolute paths from the C drive, which is why
Windows boot at all.

Next, run regedit and rename the labels on the C and D drives
(keeping their binary reference strings intact). The two keys
to cross-rename will be called
HKLM\SYSTEM\MountedDevices\DosDevices\C:
HKLM\SYSTEM\MountedDevices\DosDevices\D:
You'll probably need to do this in three steps, using a temporary
name in an intermediate step to avoid a "namespace clash".

Now you can try booting the first and the second boot profiles
in turns, watching the physical drives swapping letters in windows
with each reboot

boot boot.ini registry files mounts
-----------------------------------------------------------
bootsect0 -> rdisk0/part1 -> rdisk0/part1 -> disk0=C,disk1=D
rdisk1/part1 -> rdisk1/part1 -> disk0=D,disk1=C

When the fun wears off, remove the first drive. Just unplug the
IDE ribbon cable. Then boot the machine again.
You should notice that the second profile is defunct - the new
drive is the first one now (actually zero'th) per BIOS numbering.
Booting the first profile yields a W2k system up and running
without a hitch ))
Mission accomplished.


Please note that the boot process up to and including the loading
of registry files runs along the BIOS numbering - whereas
drive letters are mapped based on some other controller&device
identification that's picked up from the registry (PnP ID's
or some such).

It would seem that quite a large portion of the boot process
actually runs using the hardware-specific driver but still
from the drive selected by BIOS numbering - without the driver,
the boot process fails much earlier than with it...

Also, let me stress once again that you need Windows up and running
from the original boot drive but already with the new hardware
in the system - in order to install the hardware drivers, to change
boot.ini and to change the mapping of the drives.
Please note that the disks can only be cloned after the hardware
drivers are installed. Similarly, the drive letters can only be
swapped once Windows boots from the _SECOND_ profile, still with both
drives in the system.

Caveat: there's BIOS numbering and there's Windows numbering.
If your original boot drive is not the first one in the system by
BIOS numbering, or if the new drive won't retain its Windows numbering
position in the new system, modify the procedure accordingly as respects
boot.ini and the drive letters mapping in the registry.
Essentially, the drive letter should remain the same in the target
system. The BIOS numbering doesn't have to be observed as long as
the target boot.ini contains a valid entry corresponding to the
BIOS-numbered position of the drive in the target system.

All of the above is based on a compilation of previously published
information.

Special thanks to Mr. Jiri Tuma of Seznam.cz for publishing the
boot.ini syntax some two years ago.

I hope this proves useful to someone.

Frank Rysanek

 

[Scott Harding - MS MVP]

Almost seems easier to reinstall

--
Scott Harding
MCSE, MCSA, A+, Network+
Microsoft MVP - Windows NT Server

Dear fellow usenetters,

I've developed a deterministic procedure of how to
move a live Windows 2000 install to a different disk
drive on a different controller (different driver,
even externally installed).
It took me a while to figure out and I'd like to share
a summary with others.

There are occasions when you'd like to move a working
Windows install onto a new hardware setup - without
reinstalling from scratch and without repairing the
setup from an install CD, which may break applications
that are already installed, service packs applied etc.

It's not a simple as copying the files, even ghosting
the partition won't do.


Let's have a machine with a single IDE disk drive,
with Windows 2000 installed on it.

The "NT boot loader" menu is based on a file
called C:\boot.ini. This Menu currently contains
a single entry - boot.ini says something like this:

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional"

Using regedit.exe, check the disk volumes mounted - they're
listed at HKLM\SYSTEM\MountedDevices\*
Your only hard drive should be listed as something like
"\DosDevices\C:"

Consequently, the system boot goes like this:

boot boot.ini registry files mounts
-----------------------------------------------------------
bootsect0 -> rdisk0/part1 -> rdisk0/part1 -> disk0=C

Now suppose you install an exotic SCSI controller with a disk
drive attached to it (or a RAID controller of some kind, 3ware
for instance, with an array created on it). Configure the BIOSes
such that the original IDE drive is the first in BIOS order.
After you install the hardware, launch W2k from the original
C drive and install the drivers for the new disk controller
(the driver is not a standard part of the system).

Now the system contains two disk drives on two different
controllers: the original IDE "C" drive (containing Windows),
and the new drive on the additional controller (still empty).

On the original C drive, add a line to boot.ini:
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional"
multi(0)disk(0)rdisk(1)partition(1)\WINNT="Microsoft Windows 2000 Professional"

The "multi(0)" root is used for Enhanced BIOS access (via int13) - there's
perhaps never a higher-numbered multi() device. Disk() is unused with
int13 access - always a zero. Rdisk() is the drive's ordinal number
and partition() is the partition's ordinal number. All the numbers are
zero-based, except for partition which is one-based.

Alternatively, instead of the multi() root, NT4 could also use a scsi() root
with slightly different semantics and with a dedicated driver stored in
C:\ntbootdd.sys (a renamed driver file from the manufacturer's driver
disk). W2k doesn't seem to be dependent on this (the default IDE driver
is not stored in ntbootdd.sys anymore). The point is that with
the Int13 BIOS call, only the first 8 GB of the disk are accessible,
whereas via the scsi() root and native drivers, the bootloader can
reach anywhere on a huge disk and is only limited by the SCSI and
NTFS limits, which are beyond todays hardware...

Now clone the disks - use your favourite disk copy tool,
whatever it is (Norton/Symantec ghost, standard unix dd
or whatever).

We already have the W2k driver installed - without it, the
system would return an INACCESSIBLE_BOOT_DRIVE blue
screen during second stage of loading from the new drive.

Hence, now the branching boot sequence looks like this:

boot boot.ini registry files mounts
-----------------------------------------------------------
bootsect0 -> rdisk0/part1 -> rdisk0/part1 -> disk0=C,disk1=D
rdisk1/part1 -> rdisk1/part1 -> disk0=C,disk1=D

You can't remove the first disk yet. If you did, the boot sequence
would look like this:

boot boot.ini registry files mounts
-----------------------------------------------------------
bootsect1 -> rdisk1/part1 -> rdisk1/part1 -> disk0=C,disk1=D

This way, W2k stop loading just after the default blue "desktop"
is displayed. W2k actually complain about the swap file being
inaccessible - and either lock up with only the mouse moving
across the clear heavenly blue of the desktop, or repeat the
"swapfile inaccessible" message in a loop. Clearly, this way
Windows can't access the C drive.

Drive letters' mapping is set in the registry and can be changed
by Regedit.exe - which only works from graphical Windows environment.

Hence, still with both two drives in the system, boot Windows from the
_SECOND_ boot profile. This causes Windows to load from the new drive,
including the registry files - although most of the user-space
programs run by absolute paths from the C drive, which is why
Windows boot at all.

Next, run regedit and rename the labels on the C and D drives
(keeping their binary reference strings intact). The two keys
to cross-rename will be called
HKLM\SYSTEM\MountedDevices\DosDevices\C:
HKLM\SYSTEM\MountedDevices\DosDevices\D:
You'll probably need to do this in three steps, using a temporary
name in an intermediate step to avoid a "namespace clash".

Now you can try booting the first and the second boot profiles
in turns, watching the physical drives swapping letters in windows
with each reboot

boot boot.ini registry files mounts
-----------------------------------------------------------
bootsect0 -> rdisk0/part1 -> rdisk0/part1 -> disk0=C,disk1=D
rdisk1/part1 -> rdisk1/part1 -> disk0=D,disk1=C

When the fun wears off, remove the first drive. Just unplug the
IDE ribbon cable. Then boot the machine again.
You should notice that the second profile is defunct - the new
drive is the first one now (actually zero'th) per BIOS numbering.
Booting the first profile yields a W2k system up and running
without a hitch ))
Mission accomplished.


Please note that the boot process up to and including the loading
of registry files runs along the BIOS numbering - whereas
drive letters are mapped based on some other controller&device
identification that's picked up from the registry (PnP ID's
or some such).

It would seem that quite a large portion of the boot process
actually runs using the hardware-specific driver but still
from the drive selected by BIOS numbering - without the driver,
the boot process fails much earlier than with it...

Also, let me stress once again that you need Windows up and running
from the original boot drive but already with the new hardware
in the system - in order to install the hardware drivers, to change
boot.ini and to change the mapping of the drives.
Please note that the disks can only be cloned after the hardware
drivers are installed. Similarly, the drive letters can only be
swapped once Windows boots from the _SECOND_ profile, still with both
drives in the system.

Caveat: there's BIOS numbering and there's Windows numbering.
If your original boot drive is not the first one in the system by
BIOS numbering, or if the new drive won't retain its Windows numbering
position in the new system, modify the procedure accordingly as respects
boot.ini and the drive letters mapping in the registry.
Essentially, the drive letter should remain the same in the target
system. The BIOS numbering doesn't have to be observed as long as
the target boot.ini contains a valid entry corresponding to the
BIOS-numbered position of the drive in the target system.

All of the above is based on a compilation of previously published
information.

Special thanks to Mr. Jiri Tuma of Seznam.cz for publishing the
boot.ini syntax some two years ago.

I hope this proves useful to someone.

Frank Rysanek

 

[SaltPeter]

Dear fellow usenetters,

I've developed a deterministic procedure of how to
move a live Windows 2000 install to a different disk
drive on a different controller (different driver,
even externally installed).
It took me a while to figure out and I'd like to share
a summary with others.

Thanks, but such a document gets bumped to the waistebasket when one
realizes that all W2K installations rely on a SID to communicate with each
other. The bios sequence, mass storage controller issue as well as any
hardware specific issues are all secondary to that fact. As far as the
hardware issues are involved, you've also forgot to mention what happens
when the chipset on the motherboard changes. The point being that PnP can't
change a HAL.

 

[Frantisek Rysanek]

Thanks, but such a document gets bumped to the waistebasket when one

realizes that all W2K installations rely on a SID to communicate with
each other.

err... I'm a newbie, you know...
Do you mean I can't clone a single install onto several machines on a network?
Right, I know. That was not my goal.
AFAIK, in NT 4.0 there was a known trick to change the unique ID on each
machine...
Sorry if this is not what you meant.

As far
as the hardware issues are involved, you've also forgot to mention
what happens when the chipset on the motherboard changes. The point
being that PnP can't change a HAL.

Again, this was not my goal. I know that as a rule, Windows won't boot
on a severely different hardware setup.
As a matter of fact, I've managed to run a Windows install done on an
Intel 440BX on a newer system based on Intel 845. It did help me on an occasion.
I'd bet that it wouldn't work from a Duron+Via to a P4+Intel.

Thanks for your comment
Please post more information if I'm wrong again.

Frank Rysanek

 

[SaltPeter]

err... I'm a newbie, you know...
Do you mean I can't clone a single install onto several machines on a network?
Right, I know. That was not my goal.
AFAIK, in NT 4.0 there was a known trick to change the unique ID on each
machine...
Sorry if this is not what you meant.

Yes, certainly you can clone a system, assuming that the hardware is similar
on both clone and target. But my point was, if both systems have the same
SID and therfore admin account on systemA has exactly the same
computerSID::userSID as admin on systemB, how can the 2 accounts be
unique/identified on the network?

www.sysinternals has a newSID utility and Sysprep executed just before a
Ghost can help keep clones unique.

Again, this was not my goal. I know that as a rule, Windows won't boot
on a severely different hardware setup.
As a matter of fact, I've managed to run a Windows install done on an
Intel 440BX on a newer system based on Intel 845. It did help me on an

occasion.

The fix is to clone an image thats using a standard Hal, modifying drivers
and changing the HAL to an ACPI HAL once the image is cloned (not
fullproof). That a 440BX cloned image works on 845 doesn't suprise me, the
hardware rule during a clone is not a hard rule specially when the chipset
manufacturer is the same....compatibility remains.

All i'm saying is that in a network environment, hardware is just one of the
issues. There are numerous methods to deploy efficiently an image or
unattended installation that are definitely worth investigating. When you
think about it: the ultimate goal of automated deployments is a "standard
desktop" throughout the organization, regardless of the hardware.

PXE NIC + RIS, network boot disk + dhcp + ghost syspreped image,
unattend.txt, winnt.sif are all examples of relatively quick deployment
aids. And if you want an awesome ghosting utility thats too quick to be
real, try PQDI.

I'd bet that it wouldn't work from a Duron+Via to a P4+Intel.

Thanks for your comment
Please post more information if I'm wrong again.

i never said you were wrong, just that there is more that meets the eye when
doing a network deployment.

 

[Frantisek Rysanek]

I have to admit that I'm learning a lot from this thread
And during the last night I had an opportunity to test the resulting system.
It seems that the swap wasn't really all that transparent.

The windows install that was originally done on the 440BX, can't seem to
use the i845 APIC. The IRQ's above 15 don't show up. It seems that
the Windows install is using the "Standard PC" HAL - could that be the
problem?
Or maybe it's some other incompatibility that's causing my problem with this
setup. Some Dialogic hardware doesn't behave properly in such a system.
And it does behave noticeably better on Windows installed from scratch
on the target hardware (using an ACPI HAL).
As you say, there may be more than meets the eye.

The fix is to clone an image thats using a standard Hal, modifying
drivers and changing the HAL to an ACPI HAL once the image is cloned
(not fullproof).

And to change the HAL, effectively I have to run the repair option
from the Windows install CD, right? As per
http://support.microsoft.com/default.aspx?scid=kb;en-us;237556

Which will likely zap any later updates that were done to the system
- service packs and minor online updates (newer files will be overwritten
by the originals). I don't think I want to venture that...

Right, I've noticed that I can't remove the "HAL" entry itself from the device
manager - I could only remove the root of the PCI bus (as per devices
displayed "by attachment") and to my amazement the Windows managed
to boot after that...
Now I also understand that the APIC ability is something intrinsic to the
respective HAL. Unless I change the HAL, I won't be able to use the APIC, right?

Thanks for your comments regarding network deployment of clones.
This is not the problem I'm facing - my goal is to avoid complex reinstallation
of software and migration of data that's installed in the live system being
upgraded.

My current conclusion is that I'll have to reinstall anyway, to get the i845 APIC
(or HAL or whatever) installed correctly.

Frank Rysanek

 

[SaltPeter]

I have to admit that I'm learning a lot from this thread

The windows install that was originally done on the 440BX, can't seem to
use the i845 APIC. The IRQ's above 15 don't show up. It seems that
the Windows install is using the "Standard PC" HAL - could that be the
problem?

Its not the problem, and its probably why you were able to succesfully boot
the computer. Since you are using a Standard HAL, virtual IRQ tables aren't
using the bios in ACPI mode. Its just a question of changing the HAL as per:
How to Troubleshoot Windows 2000 Hardware Abstraction Layer Issues
http://support.microsoft.com/default.aspx?scid=kb;en-us;237556

Or maybe it's some other incompatibility that's causing my problem with this
setup. Some Dialogic hardware doesn't behave properly in such a system.
And it does behave noticeably better on Windows installed from scratch
on the target hardware (using an ACPI HAL).
As you say, there may be more than meets the eye.

And to change the HAL, effectively I have to run the repair option
from the Windows install CD, right? As per
http://support.microsoft.com/default.aspx?scid=kb;en-us;237556

You can't change from an ACPI HAL to Standard HAL, or from a ACPI HAL to
another type of ACPI HAL without upgrading. But Standard to ACPI is
supported as explained in the URL.

Which will likely zap any later updates that were done to the system
- service packs and minor online updates (newer files will be overwritten
by the originals). I don't think I want to venture that...

Right, I've noticed that I can't remove the "HAL" entry itself from the device
manager - I could only remove the root of the PCI bus (as per devices
displayed "by attachment") and to my amazement the Windows managed
to boot after that...
Now I also understand that the APIC ability is something intrinsic to the
respective HAL. Unless I change the HAL, I won't be able to use the APIC,

right?

No, but thats not a problem for you, since you have a Standard HAL
installed. Note that updating or flashing your bios can sometimes provide
ACPI compatibility when the old bios version did not support ACPI.

Thanks for your comments regarding network deployment of clones.
This is not the problem I'm facing - my goal is to avoid complex reinstallation
of software and migration of data that's installed in the live system being
upgraded.

My current conclusion is that I'll have to reinstall anyway, to get the i845 APIC
(or HAL or whatever) installed correctly.

You don't need to do this in your case. The problem is that if you change
the HAL to ACPI you then can't safely clone a new ACPI based image to the
next system.