Moved Windows Server 2000 from IDE drive to SATA drive now get Inaccessible_Boot_Device BSOD

Question

I'm moving my Small Business Server 2000 to newer hardware. I used Acronis TrueImage to create an image of the partitions on the current 250GB IDE drive and restored the images to partitions on a 750GB SATA drive. The new mainboard is an Intel D915GEV.

When I boot the system it makes it part way through then BSODs with:

STOP: 0x0000007B INACCESSIBLE_BOOT_DEVICE

If I boot in safe mode I can see that it's loading lots of drivers and the BSOD happens when it tries to switch into the graphical boot. That means the drive isn't totally inaccessible.

I'm currently operating under the theory that this is caused by the fact that my original Server 2000 doesn't have drivers for the SATA controller on the new motherboard. The early part of the boot process must be handled by the BIOS and it only fails when Windows tries to take over the file access.

I know you can use F6 during a fresh install to add drivers but that doesn't seem to help me since I'm not installing fresh. Even so, I have not been able to track down SATA drivers for this board even though I have found all the other drivers on Intel's site. It appears that there aren't specific drivers for the SATA controller.

What's the best way to handle this?

I made sure I can always go back to the old hardware but I'd really like to get this running on the newer hardware. The hardware is pretty similar - it's not like I'm doing a major hardware upgrade, it's even the same processor and this mainboard is really similar to one this install used to run on. (The old hardware failed so I had to quickly move to new hardware, now I'm trying to move it back to the replacement hardware Intel sent as a warranty replacement.)

Answer 1

There is the chance that if you enter BIOS and move AHCI to ATA (I usually poke around until i find it, as all BIOS are different) that it will allow you to install the OS. After this, you can look for drivers from your motherboard's chipset manufacturer that will allow you to change it back after you have loaded your OS. Hope this helps, Good Luck.

Answer 2

This is probably going to be an unpopular answer, but here goes...

What you're doing may seem trivial, but it's not. Disk imaging software makes it easy to do things that the operating system can't cope with easily. Micorsoft doesn't officially "support" moving installs of Windows between different makes or models of computers or motherboards (see http://support.microsoft.com/kb/249694). You're not going to have an easy road of this if you try and do this in this fashion.

If what you're doing is a permanent move I'd really recommend a clean installation as a secondary domain controller and a migration of SBS from one machine to the other (here's the procedure for Windows Server 2003, but it doesn't go thru doing a "swing" migration through a temporary computer to preserve the original server computer's name: http://technet.microsoft.com/en-us/library/cc747454(WS.10).aspx).

Disk imaging the machine and moving it to another box is seductive but you're not doing anything to help the resulting machine's stability.

The "swing migration", very briefly and at a high level, is as follows:

• Put up a temporary W2K DC joined to the existing domain.
• Install Exchange 2000 on the temporary DC and join it to the Exchange organization.
• Move all the mailboxes to the temporary server. Replicate the public folder hierarchy and remove replicas on the original Exchange 2000 server.
• XCOPY off all the shared files on the original server computer, preserving permissions. Document the existing share structure (or just export the shares from HKLM\System\CurrentControlSet\Services\LanManServer\Shares).
• Transfer the FSMO roles from the existing server computer to the temporary server. SBS will begin to blue-screen every hour (if I recall properly) because it's not the role holder for all the FSMO roles anymore.
• Make the temporary server comptuer a global catalog server and verify that global catalog replication completes.
• Demote the existing server computer to a member server and remove it from the domain.
• Make the temporary server a DNS server.
• Install Windows 2000 SBS on the new server naming it the same as the old server computer's name. During the setup prevent the installation of Active Directory from occurring automatically and manually install AD (after "pointing" the DNS on the new server to the temporary server) joining to the existing domain.
• Transfer the FSMO roles over to the new server computer and complete the SBS installation.
• Move all the Exchange mailboxes to the new server. Replicate the public folder hierarchy and remove the replicas on the temporary server.
• Retire Exchange on the temporary server.
• XCOPY all the shared data from the temporary server to the new server. Recreate shares on the new server and verify that you can access them.
• Demote the temporary server back to a member server and remove it from the domain.

I'm missing a lot of tiny little steps in there and, to be honest, I can't remember if that whole procedure works on SBS 2000 or not. If I were doing this I'd bring up SBS 2000 in a lab on a VM, populate it with some bogus users, mailboxes, public folders, and data, and then do the entire migration scenario from top to bottom twice (once making notes and gathering data, and the second time as a "dry run".)

Answer 3

I found it. All it takes is adding a registry key.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters

Add EnableBigLba as a DWORD value and set it to 1

Here's the longer explanation if you're interested:

Windows 2000 Server was made before drives got bigger than 128 GB. Therefore, it can, by default, only use 128 GB of the drive. If the drive is bigger than that, even if the boot partition is smaller it appears that it can't read the partition table correctly. The solution is to add that registry key before putting it on the new drive. There's an MSKB article about it here.

I found this by restoring the image of my boot drive on an old 40 GB PATA drive I had laying around. I booted it up on the new hardware and installed all the drivers for that mainboard. Then I shut it down and connected up the SATA drive. When I rebooted the 750 GB SATA drive with multiple partitions appeared as though it had a single unformatted 128 GB partition. With some research I found out about the EnableBigLba registry key. I set up that key and rebooted and the SATA drive showed up with all it's partitions. I imaged the updated version of system drive and applied the image over the primary partition on the SATA drive. Then I removed the PATA drive and the system boots up now using just the SATA drive.

Now, I'm not saying this is the best way to upgrade a Small Business Server. I'm sure Evan is right about a server migration being the "best" way to do it but I've already invested enough time in this and my window of opportunity for the server changes is about to close.

I'm thinking now that I have a working image of the drive I'm going to try an in-place upgrade to SBS 2003. It will only take 30 minutes to roll back to where I am now if things go haywire.

Answer 4

How about using the free Hyper-V Server on the new hardware and converting your SBS server to a VM? You'll need a PC with Vista and the Hyper-V management tools to manage the Hyper-V Server.

JR