Real World Computing

To be fair, there are a few other interface components, including Notepad, but this really is a hands-on, down-and-dirty OS. Server roles included with it (although only File Server is installed by default) are DHCP Server, DNS Server, Domain Controller, File Server, Print Server and WINS Server. The file server role has to be installed to enable remote access to the server, which will of course be via the Command Prompt interface. In addition, the server supports clustering, load balancing and all the other goodies you might have expected to find in a pure server system, but it does so using a far smaller memory footprint than a traditional GUI-based server. Some might see it as a disadvantage that Microsoft .NET Framework isn't supported, but others will breathe a sigh of relief that they have a server that's going to be a lot less vulnerable to attack, because so many of the attackable services simply aren't present. I might have a go at setting up a core server in the future, but for now I'm turning to my shiny new Windows Server 2008 graphical user interface and about to start work with the Server Manager. See you next month.

David Moss

VM Nettle grasped

Another thread that came out of the recent Microsoft Management Summit 2008, held in the delightful Venetian Hotel in Las Vegas, is that Microsoft has really grasped the nettle when it comes to virtualisation - not only whole machines, but also applications and services, too. Not surprisingly, a number of its partners are building on this core work, and I was particularly impressed with the tools demonstrated to me by Quest, which allow for incredibly powerful provisioning of virtual machines, applications and so forth. If I were running a university and needed to prepare a pile of computing resources for the new year's intake, I'd start here.

In the keynote address, Microsoft demonstrated its take on the virtual desktop infrastructure. What this means is that your desktop might be a real OS running on your local machine, or it might be an OS Terminal Server session running on a server with its whole UI provisioned via Terminal Services in the usual way. Or it might be a Virtual Machine running on a server somewhere, with the UI provisioned via Terminal Services. Or it might be an application that's running in a VM, provisioned onto the desktop of any of these. Or it might be an application that's being demand-loaded (and unloaded) onto the desktop of any of these solutions. Or it might be a mix and match of any of these core models. You might have a base OS desktop with your Office applications provisioned through "install and run on demand" Softricity capabilities, and a big line of business application provisioned through a VM application window.

The reason for the choices comes down to one of control. Having an app surfaced from a VM means I get my own space in the VM environment, much more so than I'd get in a Terminal Server session, for example. But the data is still locked away in the back end. How many times would this have been useful recently, when we've heard stories of mass data loss from so-called professional organisations? Yes sir, client/server keeps your data remote, but now you can remote the client as well.

Better still, let's do all of this in a demand-based manner, so that your first few runs of Office might come via Terminal Server session but once you've proved the need, the system might switch you over to a demand-loaded application. If you're a laptop user, you could either take the demand-loaded app offline, or else go for a full-blown local installation. In essence, it's going to be very difficult to know now, when you're peering at a desktop, where the various parts are all coming from. Some might be local. It might all be remote, but some of it more remote than others. Getting your head around this virtualised locality is going to be a key driver in making all of this work.

Continued....