Home > Articles > Operating Systems, Server > Microsoft Servers

Windows Server Reference Guide

Hosted by

Microsoft vs. Virtual Microsoft

Last updated Sep 26, 2003.

When Microsoft took over control of the universe, many did not expect the level of communication between compartmentalized segments of the universe to be more separated, divided, and distanced than earlier in the universe's history. Back then, all we had to contend with was the vast interstellar distances between stars, and star systems owned by different, yet competitive, firms.

After Microsoft released Service Pack 1 for Windows Server 2003, Microsoft officials admitted to a few problems (and it's to their credit that they did so). One was that SP1 could introduce a breakdown in interprocess communication between processes that authenticated themselves in Windows using a insecure technique known as "the wrong way." So, for enterprises to test what SP1 would do to their applications, Microsoft suggested that they install Virtual Server 2005 on a computer system. Then, try out the application in a safe, virtual environment, before discovering an anomaly in the real world where there could be danger.

This sounds pretty logical on the surface. The trouble is, among all the applications in the world that could potentially have trouble with WS2K3 SP1, one was a set of drivers called Virtual Machine Additions. It's Microsoft's package of "fake" drivers that enable a guest operating system (running in a VS 2005 subsystem) to utilize the resources of the real, physical machine without having to pretend they're using real, physical resources. For example, rather than run a real mouse driver — that is sensitive to input being supplied by a back-end driver that is translating motions from the physical mouse by way of an ActiveX control (a scary thought in and of itself) — a virtual mouse driver could accept events directed to it via the same ActiveX control, though at far less frequent intervals, thus speeding up the virtual computer substantially.

Virtual components in the simulated realm of VS 2005 are represented by drivers that give the appearance of being hardware drivers, for applications running in the guest OS. They don't have to "inform" anything in the guest OS that they're virtual; they simply behave virtually, within their own unique confines. Among the wonders of this virtual world is the VM driver for the non-existent S3 Trio/64 graphics card. For the rest of the applications within the virtual world, this VM driver gives off the signals that it's connected to a fairly common card without 3D acceleration.

But to pull this off, VM components, already living a good part of their lives "under the rug," became violators themselves of the rules which WS2K3 SP1 (and Windows XP SP2, for that matter) would operate. Yet in a fashion which even Antoine de Saint-Exupéry would consider self-centered, the Microsoft division in charge of physical servers left it up to the developers of the virtual servers to figure that part out for themselves, hopefully by trying out their product through one of those new virtual...no, wait, you can't virtualize a virtualizer, can you?

In any event, a good many galactic citizens tried out WS2K3 SP1 on their existing VS 2005, including myself. And what to our wondering eyes did appear... but the annihilation of the virtual network, a virtual storage device, and the virtual mouse? For the VS 2005 team to solve the problem, they had to develop a service pack for themselves, which meant that the entire virtual project had to re-enter the beta stage.

In the meantime, some enterprising individuals discovered something which Microsoft itself didn't know, or didn't virtually appear to know: In a separate division, orbiting a moon of a distant planet, within a separate product line called Virtual PC 2004, was a second set of virtual machine additions. Once one installs Virtual PC, he can extract from its program directory the .ISO image of the fake CD that contains an upgraded version of the Virtual Machine Additions file. When Virtual Server is made to "capture" this .ISO file, the virtual server acts as though someone inserted a new CD into its drive. That starts a setup process, which installs new VM files...and, to my partial yet virtual delight, I get my network back. What this means is, my virtual server can now see the other computers in my actual network, which gives me a way to transfer files to the server without pretending to burn a CD (You think I'm kidding?) and then passing the .ISO image of that CD onto the virtual drive capturer.

But alas, the VM mouse still has trouble, and the virtual network, though existent, is still slow. Here is where the beta team from VS 2005 re-enters the picture: Seeing how much work they had to accomplish, the team re-christened itself the VS 2005 R2 team (insert appropriate "Star Wars" joke here). Their job was to test a whole new set of VM drivers that not only performed the same job the old set did, but to do so in such a way that the drivers appropriately authenticated themselves to the guest operating system. In other words, rather than lie to the guest OS (which is what they used to do), they had to tell the truth in such a way that the guest OS not only accepted it, but didn't really care and let the drivers run anyway.

In typical Microsoft fashion, the following chain of events ensued:

  • First, the VS 2005 SP1 beta was launched; then, assessing the critical nature of their work, the team made it the VS 2005 R2 beta. They worked diligently to solve the problem. Users having trouble with WS2K3 on VS 2005 were told to join the R2 beta. This, said Microsoft's technical support, was the only channel for finding the working VM drivers.
  • Microsoft had too many people requesting to join the beta, so it simply turned over the beta invitation password to the general public. There, everyone and anyone could join, and to heck with security. (The latter phrase had previously been rumored to be a mantra, though this has been vigorously denied...through channels, of course.)
  • The fact that the VS 2005 R2 beta was now going in full swing meant that Virtual PC 2004, which already had an SP1 of its own, could be relieved of having to service all those VS 2005 complaints.
  • With the heavy number of beta participants in the R2 beta, the VS 2005 team's mission succeeded ahead of schedule. Since it succeeded, Microsoft could effectively shut the beta program down.
  • In so doing, the company closed off customers' only channel to the working VM drivers. In the meantime, select developers to the MSDN network were redirected to a "new and improved" link to VS 2005, where they would find themselves downloading the old drivers that caused the problem in the first place.
  • And until the marketing division catches up to the fact that the development division is actually done, they can't put the working product in a box and sell it to people so their pilot migration projects will work.

References

  • "Microsoft Virtual Server 2005 R2 Beta Program." Here, you can learn more about how to receive a replicated invitation to join a beta program which distributed the only working copy of a product that can't be distributed yet because marketing isn't ready, and can't be distributed through beta any more because it's finished and it works.