Not so long ago, I made a disturbing discovery. My P6DBE box was only showing one of 2 PIII 700 processors in the task manager. I assumed that since the system had been up for quite some time and that because the pins holding the CPU and heat sink together were only narrowly avoiding hitting the capacitors, that with heat expansion, one of the CPUs had worked its way loose.
I discovered otherwise after opening up the system. The CPU in slot 2 had scorch marks on one corner of the circuit board. Oddly enough, the CPU that failed was not the one that had pins barely clearing the caps. I've never seen a cooked CPU before, but this CPU was fried, but oddly the processor itself looked alright, just a corner of the connector to the MB slot was cooked. I temporarily put in the PII 450s that originally went on the MB years ago, and both CPUs registered in the BIOS, this was good, however, if one CPU has been fried, the MB was now suspect.
I pulled the MB and went out in search of a replacement board & CPUs. Seeing as how that this was a slot 1 dual board that failed, I would need to get a trio of new hardware, CPU, MB, and RAM. I picked up a P4 (Willamette) 1.5G. I didn't need anything fancy, and it was under $75 (circa Spring 2005), and a basic Gigabyte board (the 2004 RZ - GA-8S648FXP-RZ) as well as a stick of 512MB DDR333 RAM. I didn't need this box to do anything fancy. It would now be twice as capable as the previous system, which only had 384MB RAM & in the end a lone PIII 700 (PC100). This box served as my DHCP and fileserver on my home network (well, a few other things too, but that's another story!). It wasn't like this was a high end box that was mission critical or anything, so power wasn't a major issue, just budgetary affordability and wanting to the box back on line.
The next major hurdle after getting the system back on line was getting Win2K Server to boot, without doing a complete reinstall (I didn't want to go through reconfiguring all the services and all the ick that goes along with setting up a new box). I ran across an article that said how to do the upgrade in place. I had tried doing a "repair install" several times, but continually received the INACCESSABLE_BOOT_DEVICE error.
The most first article from Microsoft would have you make sure you move the drives to "the same hardware" or "hardware components with the same model and the same series" which really isn't an option, while I can find similar boards on eBay - they are all used, and will probably just buy some time, $55 for a board that might not last but 6mos is not my idea of money well spent. Another article that outlined how to repair your install if your motherboard fails was a bit closer to the mark. I think it is unfortunate that KB 268066 does not suggest KB 824125 as a way of getting around a hardware scarcity issue (which was my problem).
The new method said to begin by choosing a new install, but then the install script would detect the current install and offer to repair it. This repair is not the same as the repair that an initial selection of "repair install" would take you to, but a "drastic" reinstall of the system files. It clobbers most of the system drivers & parts of the registry, but leaves preferences and configurations mostly untouched. This install mostly acts like a new install, but only asks a few questions, and then copies files left and right. It never asked about the box name or administrator password because those were already set.
When it finished, I rebooted, I was pleased to see that the computer booted right into Windows and I easily signed in. My desktop looked like I remembered it, I did have to change explorer to use detail rather than icon view, but it had preserved my election to show all files & all file extensions. IIS was working, my IE preferences (internet cache size, homepage) was the same as previous. It looked like upgrade-repair in place was just what I needed... until I discovered that Terminal Services didn't run.
I was able to WinVNC into the box with no issues, but I kept getting cryptic messages from the client when I was trying to connect to the box. I never had any Terminal Services events logged on the server. I couldn't telnet to the box on port 3389 - which was a bad sign. The services manager showed the service listed, but start/stop were disabled... This did not bode well.
I found a number of articles where others had faced this problem, and no one had posted a solution. In fact, I found some reference to it on MS, but they recommended just reloading the box, I felt like that was too pat of an answer. I had already tried unloading and reloading the service several times, as well as a "standard" repair install, probably more commonly known as "emergency repair".
I had a back up image of the disk, so if I hosed the box, I'd just restore; the system drive was only a 2.5GB image. I started picking through the registry, it looked like portions of terminal services were missing or incomplete when compared to another box that worked. I figured, what the heck, why not, so I started exporting a few parts of the registry from one box and then registering on the handicapped one. After rebooting, and trying the client again, I got a different message, and I could telnet to 3389 now, but I still wasn't in. I looked in the event log and found a tech article based on the logged event. Microsoft's article said delete a particular key because your certs are probably out of synch. I did this and rebooted. This time terminal services loaded right up and there was much happiness in the LAN!
Now a word of warning here, if you damage the registry, don't come crying to me. When you decide to modify the registry you assume the risk, if you don't have a backup or if you don't know what you are doing, that's your problem!
I rather like the way Microsoft puts it: WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
First, take a look at these articles:
KB 824125 - How to replace the motherboard on a computer that is running Windows Server 2003, Windows XP, or Windows 2000
KB 323497 - "The RDP Protocol Component "DATA ENCRYPTION" Detected an Error..." error message
After your box is back on line from the repair, you will most likely get the message "The server may be too busy" from the Terminal Services client when attempting to access the box remotely. You will also be unable to telnet to the box on port 3389 and will probably not see anything in the event log since the connection was never made.
Now, go to a box that has working terminal services access (this should be a box of same OS version & SP#) & export these keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService
Now, go to the box that doesn't work, and load the registry files. You can either reboot and confirm the certificate issue and modify that key and reboot again or go ahead and delete the certificate key, but I haven't tried this second way. If you choose to perform the two boot process you should be able to telnet to port 3389 (but get a 'connection refused' error) as the service is now running after the first reboot. After the second boot you should be able to access the service through the client.
The above system has since been upgraded (circa Fall 2007) with a used P4 (Northwood) 3.06G (HT) processor and has been switched to a 1GB stick of PC400 DDR memory as well as being upgraded to Server 2003.
On another note, I have since had cause to perform a planned move from a 440BX (Slot 1 PII/PIII - GA-6BXC with a PIII 700-100 Coppermine) board to an 815E board (Socket 370 PIII - D815EEA with a PIII 933-133 Coppermine) board for another system. To move the existing hard disk I simply changed the IDE controller from the chipset specific version to the generic IDE controller as seen on Windows Reinstall. I then took the existing hard disk and attached it to the new system's motherboard et voilà, the system booted right up, no "INACCESSIBLE BOOT DEVICE" BSODs. By changing the IDE controller to "generic" I was able to completely bypass the need to do an upgrade/reinstall and all MS updates remained intact rather than having to sit through dozens of reinstalls with reboots to get the patch level back up to par with pre-move levels.