A very long time ago I managed a server with some websites on it. So long ago, in fact, that this "cutting edge" deployment was on Windows 2000 Server. I made a virtual machine backup of this server at the time, burned the files onto a DVD and filed this away in case I ever needed it. And recently I had reason to want some data off this ancient machine. I was able to get it fired up, but it took a little effort to get there. It feels like a minor miracle that I was able to make this run, so I wanted to write down some of the things I messed about with - partly so I'll remember if I ever have to do something similar again, and partly because this might be of interest to (a small number of) others too...
The DVD I'd filed away had three files on it. Two were VHDs - binary images of the hard drives from the old server. And the third was a VirtualPC config file which I'd been using to run this VM when it was originally created.
My first thought was "head off to MSDN Downloads, and see if I can coax VirtualPC into life on a modern PC". If that could work I already had all the relevant config to make sure the VM was set up the same way the original was. And remarkably after all these years, you can still download it:
But trying to install that was not successful:
A "certificate for the signer is invalid" error doesn't sound like one I'm likely to be able to resolve. I suspect that's down to Microsoft, and they way security tech has advanced. When I look at the installer's details it shows a SHA1 hash in the code signing certificate:
And that's old signing tech. It looks like Microsoft stopped supporting this back in 2017 because these hashes were no longer strong enough to be safe with modern hardware...
So just using VirtualPC didn't look like it would work.
So what replaces VirtualPC for modern virtualisation? The first thing I thought of was VirtualBox. That's a similar concept to the older VirtualPC, but it's modern tech and able to run happily on my current computer. And I had it installed anyway. So I tried creating a new VM using that tool.
I created a default VM by attaching my VHD files, telling VirtualBox I had a Windows 2000 VM to run, and turning the video device down to the basic VGA that the UI recommended for Win2k. And initially VirtualBox was happy to create this:
Unfortunately though, starting that would initially boot, briefly show the Windows 2000 boot screen and then crash:
That's a kernel error about "INACCESSIBLE BOOT DEVICE". While that sounds nasty (Kernel errors can't be good, right?) it's not as bad as it sounds. Back in the Windows 2000 era, the kernel was much less good at dealing with hardware changes. Nowadays Windows can reconfigure itself more easily at boot time, so it's much better at dealing with "I had a device configured, but the hardware changed since last time I booted" - but back then many hardware changes would cause a crash by default.
Thinking about the error, I figured this probably means something along the lines of "the drivers configured on the boot VHD cannot provide the boot device Windows was expecting". Given that VirtualBox allows a variety of different disk drivers, I wondered if that might be a setting to tweak. And looking at the default config that the setup wizard had created I could see an issue:
The default here has created a SATA device, but I know that back in the day the actual server had IDE controllers not SATA. So I tried updating that config to use VirtualBox's PIIX4 device:
And that worked better. Restarting the VM now booted:
Though while I did now have the Windows login page for Win2k, it was also showing a "one or more service or drivers failed during system startup" message.
But in this state, I found I couldn't make it respond to the mouse or keyboard. Even though VirtualBox thought it had captured the mouse, no cursor was visible. And neither hitting real keys, using VirtualBox's virtual keyboard or using its menu shortcuts for sending keystrokes like
Ctrl-Alt-Delete
had any effect on the VM either.
I tried a variety of settings in VirtualBox to attempt to address this. There are options for the mouse and chipset settings which seemed relevant. But changing these didn't resolve the issue:
The VM continued to boot, but still showed the "can't start device driver or service" message and did not respond to the mouse or keyboard.
I spent a chunk of time in Google looking for answers to this, but failed to find anything which would resolve the issue.
At the back of my mind was the idea that while VirtualBox is good, it's not Microsoft tech. Maybe trying Microsoft's newer virtualisation software would help me. And what is Microsoft's replacement for VirtualPC? That's Hyper-V. While this was originally server-only tech, it is possible to run this on Windows 10 these days. If you don't have that installed, it can be added via the "Turn Windows Features on or off" dialog:
For my first pass at this there was only one interesting setting in the "add a VM" process that I thought I needed to be careful of:
Hyper-V supports both "old" and "new" style VMs, and I guessed that this would need to be the "old" style for an ancient VM to work. And having given this a chunk of RAM, and attached my VHDs as I did for VirtualBox it worked:
The keyboard and mouse worked fine here - and I didn't see the "failed to start a driver or service" message on the lock screen. (which makes me fairly confident that the broken thing in VirtualBox must have been something to do with the keyboard / mouse stuff) So it seems Hyper-V has some more backward-compatible emulated devices available here.
And with that working I was able to start up the software installed on the VM - an ancient homebrew CMS originally written in .Net 1.0 - and extract the data I needed. Remarkable how it's possible to run a 20yr old VM still - that level of back-compatibility impresses me, given how much the hardware and software have changed in nearly 20 years...
↑ Back to top