Hyper-V and Legacy Applications (Part 1)

If you would like to read the other parts of this aritcle series please go to:

Introduction

Hyper-V is a great solution for consolidating physical servers that do not fully utilize the hardware that they are installed on. Even so, virtualizing may not be the best option when it comes to legacy servers. This article explores the reasons why.

Let’s begin

One particular aspect of server virtualization that a lot of people seem to be interested in lately is legacy application consolidation. One of the issues that server virtualization was originally intended to address was hardware underutilization. In the past, corporations have often used a dedicated server to run an application that does not actually use all of the server’s resources. Virtualization allows a single physical to host multiple virtual machines, none of which would take full advantage of the server’s resources by itself.

On the surface, this idea seems absolutely perfect for running legacy applications and operating systems. Take for example one of my clients who is still running a DOS based accounting package. This application has not been updated in many years because the company that made it went bankrupt, but the company considers the application to be mission critical, so they continue to use it.

Believe it or not, the application is actually reliable, but what may not be so reliable is the server that it is running on. The application is running on an absolute dinosaur. On top of that, the server is still running Windows NT 4.0.

Off of the bat, this server seems like a perfect candidate for virtualization. The hardware that is in use right now could fail at any time, and replacement parts will be difficult, if not impossible to come by. Furthermore, the application is so old that the load that it would place on modern hardware probably would not even be noticeable.

Although it is tempting to virtualize this machine, there are certain things that you have to consider. For starters, there are only certain operating systems that are supported for use with Hyper-V. Microsoft officially supports: Windows 2000 (with one virtual processor), Windows Server 2003 (x86 or x64 with either 1 or 2 virtual processors), and Windows Server 2008 (x86 or x64 with 1, 2, or 4 virtual processors). Microsoft also supports a few miscellaneous server operating systems such as Windows HPC Server 2008 and various Linux deployments. If you want to run a client operating system in a Hyper-V environment for some reason, then you can get away with running Windows XP (x86 and x64) and Windows Vista (x86 and x64 with one or two virtual processors). My point is that Windows NT and DOS are not on the list.

Before you just give up though, it is important to keep in mind that just because Microsoft does not officially support something, it does not mean that it would not work. Before I go on, let me just say that I have to keep the lawyers happy by saying that I would never recommend running an unsupported configuration. Doing so can cause all sorts of problems.

Having said that, I do know of situations in which unsupported configurations seem to work fine. For example, Microsoft does not support running Exchange 2007 in a Hyper-V environment. Even so, I virtualized my own Exchange 2007 servers before Microsoft had announced that they were not going to support that configuration, and it seems to work flawlessly. If you are reading this article right now, then it proves that I was able to E-mail my manuscript to my editor using my Exchange 2007 servers.

OK, so what about legacy operating systems? Well, even though Microsoft does not officially support running Windows NT on Hyper-V, their Web site strongly hints that it will work (www.microsoft.com). Essentially what the site is saying is that you can run Windows NT in a virtual environment, but doing so does not extend Microsoft’s support for Windows NT.

Even with this in mind, there are still several challenges that you will have to overcome if you want to use Windows NT or some other legacy operating system on a Hyper-V platform. One of those challenges is the installation process itself.

In preparing to write this article, I spent a couple of hours digging through my archives until I found my old copy of Microsoft’s BackOffice Server. For those of you who were not in the field in the days of Windows NT, BackOffice Server was kind of like Microsoft’s greatest hits collection. It consisted of a single license that covered Windows NT Server, Microsoft Exchange, SMS Server, and a few other Microsoft server products.

At any rate, I inserted the Windows NT installation CD into my Hyper-V server, and guess what…. The CD was not bootable. During the time when Windows NT was the current server operating system, bootable CDs either did not exist yet, or they were just coming onto the scene (I forget which). Since you could not boot from a Windows NT CD, Microsoft gave you two different methods of installing Windows NT.

One method was to start out by using three boot floppies. These floppies loaded the necessary drivers that allowed the CD portion of the installation process to start. The other boot method involved booting the machine into MS-DOS, loading the drivers for the CD-ROM drive, and inserting the CD. From there, you had to navigate to the CD’s \I386 folder, and then run the following command:

WINNT /B

This command told Windows that you wanted to install solely from the CD without using the boot floppies. I actually had a set of boot floppies that I had kept for all of these years. As if that was not miraculous enough, when I built the server that I am running Hyper-V on, I had an extra floppy drive laying around, so I decided to install it into the server just in case I would ever need one (not that I realistically expected to ever need a floppy drive again).

With that, I inserted the first boot floppy and started the new virtual machine. Of course Hyper-V did not recognize the floppy. I started thinking about how Hyper-V requires you to capture the physical drive if you need to access a DVD, so I thought that maybe Microsoft had done the same for floppies. As it turns out, there was such an option, but here is the catch… You can only mount a virtual floppy disk. Hyper-V offers no support for physical floppy drives. This means that there is no chance of using the boot floppies to install Windows NT on a Hyper-V server.

The other installation method is still a possibility, but in order to make that work, you have to have a way of formatting the virtual hard drive so that when the virtual machine is booted, it boots into a DOS environment.

Conclusion

Unfortunately, I just did not have everything on hand that I needed to make a DOS bootable virtual machine in time to make the deadline for submitting this article. Even so, there are still a lot of questions that I want to answer in regard to using a legacy operating system and legacy applications in a Hyper-V environment. As such, I am going to attempt to get Windows NT functioning in a virtual environment before I write Part 2. My plan is to explain how I was eventually able to complete the installation process, and to talk about some other compatibility issues that may rear their ugly heads after such a deployment.

If you would like to read the other parts of this aritcle series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top