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

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".)

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.

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