Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question

4 Answers 4

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.

share|improve this answer
    
In the BIOS,Advanced > Drive Configuration Menu Configure SATA as… –  JS. Jul 15 '09 at 21:21
    
Advanced > Drive Configuration does not have an option to change how SATA to ATA. It only allows me to configure LBA, Block, PIO, DMA and SMART. Looked through the BIOS and it doesn't look like there's any AHCI to ATA option. I checked the BIOS version and it is up to date. –  Steve Hiner Jul 15 '09 at 21:37
    
What BIOS are you using? –  RascalKing Jul 15 '09 at 21:48
    
take a look at the BIOS settings glossary pdf on this page. intel.com/support/motherboards/desktop/sb/cs-020304.htm –  JS. Jul 15 '09 at 22:12

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

share|improve this answer
    
I don't think it can be stressed enough that imaging onto new hardware is unsupported and likely to cause issues. –  Jim B Jul 16 '09 at 20:49
    
I have a really narrow window for this upgrade. That's why I kept the old server in totally working condition, just shut down for the moment. I think you're right that a true migration is the best way but my bosses don't want the server name to change so I'd have to do a swing migration and I don't have time for a double migration at this point. I'll see how an in-place upgrade to SBS 2003 goes and maybe later I can get newer hardware and try a swing migration to 2008 the next time both my bosses are out of town. Thanks for pointing out that migrations are better. I up-voted you for that. –  Steve Hiner Jul 16 '09 at 20:50
up vote 1 down vote accepted

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.

share|improve this answer
    
If you've already had (and clearly realize tht this isn't the best way to go) why would you upgrade- even if it works? –  Jim B Jul 16 '09 at 20:52
    
I need to move the install to other hardware because the hardware it's on doesn't belong to us. We had a hardware failure a couple years ago and in the interest of getting the server back up and running quickly we ended up using some spare hardware one of the employees owned. That gave us time to RMA the original gear and get it replaced. That employee left the company more than a year ago and I'd really like to give him his system back. I work for a very small company, just 6 employees, so this isn't like an enterprise level server with 1000 users. It's desktop level hardware running SBS. –  Steve Hiner Jul 16 '09 at 22:50

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

share|improve this answer
    
The hardware I have doesn't support Hyper-V. I wish it did. –  Steve Hiner Jul 16 '09 at 20:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.