While preparing for Filter 3 (which goes live on April 7), it fell to me to create a segment on good security ideas we'd run across in the realm of virtualization. I put four together in all, but the first seemed like the one that was the one least talked about. So i thought I'd share it here in advance.

Indeed, the first idea almost doesn’t look like virtualization – it’s Microsoft’s “Click to Run” technology and it’s what Microsoft is using to sell Microsoft Office to home users, although they’ve built a framework that enables them to use it in any arbitrary situation including enterprise application deployment management.

It solves a problem that, on the face of it, has nothing to do with virtualization. As a home user, you decide that you want to buy Office and you’d like to start using it as soon as possible. For some reason or another you need to work with a spreadsheet, the need is immediate, and you’ll pay right now for an immediate response. Of course, Office is a huge package and it will take a while to download. In fact, if you’re not using a fast Internet connection, it’s going to take you hours.

What Click to Run does is give you is establish a beachhead for your application on your local machine. The application runs in a virtual environment (this is provided by Microsoft's AppV) and then draws down components as needed (and in the background) as you need them. What’s cool at this point is that the balance between the beachhead and the application still on the server shifts gradually and without the user being aware of it (well, for the most part).

At first, nearly everything is running on the server, although all the files you create and the settings you configure are stored locally. And it’s true that if you pick a feature to use that isn’t loaded locally, you may see that a little notice pops up in the bottom right of your screen to tell you that the application may be unresponsive while it’s catching up with you. You’re running a virtual instance of an application where some of the code is local and some of the code is remote. Gradually, as time and bandwidth permit, the balance of what’s running on the server image and what’s running locally shifts till you’ve got the application loaded locally in full. At this point, the remote server is used entirely for seamless product updates.

Lurking in this idea—and not lost on Microsoft-- is the solution to managing enterprise notebook fleets. The applications are fully available offline, but they are running virtualized. This is better than just having automated software update, in my view, because when you run the application locally, it runs inside a virtual component manager.

And that virtualization of the application environment gives us an important opportunity for security -- ability to detect and destroy instances that are trying to attack the operating environment.

Catch the other three ideas during Filter 3 on April 7.

-- Robert Richardson