By Cameron Sturdevant  |  Posted 2006-04-02 Print this article Print

Altiris Software Virtualization Solution eliminates application conflicts in Windows systems by controlling how application files and registry settings are installed.

During tests, SVS enabled eWEEK Labs to install and then activate a wide variety of productivity applications without having to test for possible conflicts prior to deployment.

This first version of SVS—called, go figure, 2.0—is not intended to virtualize utilities that load early in the Windows boot process, including any tool that uses a file system filter driver, such as anti-virus software. This stricture also includes printer drivers. Altiris officials said a follow-on version of SVS will include the ability to virtualize even these early-loading utilities.

There are two SVS flavors: a no-cost, stand-alone SVS agent intended only for personal use and the "solution" version that we tested, which costs $29 per seat and requires installation of Altiris Notification Server, available at no additional cost.

Click here to read more about the software giveaway. Using SVS to prepare and deploy an application is similar to the way youd use any application software packaging tool. First, start with a base PC running the same operating system as the target systems. Then, install the SVS agent on the base machine so that it can record all the file and registry changes made during installation. Save the reference file and then use a deployment system to distribute the package to the target systems.

Simple, really.

The complex aspect of SVS was revealed when we started using the system to create what Altiris calls "data layers" for our virtualized applications. To explain, its necessary to take a step back and describe the Altiris SVS nomenclature.

To start with, VSP (Virtual Software Package) is the Altiris term for captured data managed by SVS. In our tests, we created a Microsoft Visio 2003 VSP by installing Visio on our base system.

Altiris uses "layer" to refer to all the files and registry settings that make up a virtualized application or the data associated with that application. In our case, we layered the Visio VSP on top of our base Windows XP operating system.

Finally, a VSP layer can be saved and then deployed to other target systems with the SVS agent. Altiris calls this a VSA (Virtual Software Archive). We used SVS to export the Visio files and registry settings to a VSA that we then distributed to machines in our test network. After the VSA was loaded on the target system, we imported the file and registry settings.

We then accessed the simple SVS administration interface and activated the VSP, which made Visio almost instantaneously available on our target system. It was just as easy to deactivate the VSP, which made Visio not only unavailable but also invisible on our target system. We also used the SVS interface to reset Visio after we purposely damaged several DLL files. And we did all this in about 10 minutes.

To read more about eWEEK Labs first impression of SVS, click here. The other half of the Altiris SVS equation is how the user interacts with the tool. In this regard, IT managers will likely have their hands full with user training.

For example, with the Visio VSP active, we created a shortcut on the desktop to access Visio. When we deactivated the Visio VSP, the shortcut remained on the desktop. When we double-clicked on the shortcut, we received a Windows error message saying that the action was not valid for currently installed products.

On the one hand, this error message is correct because, with the Visio VSP deactivated, Visio was, in fact, "not installed" on the system. Support staff at Altiris indicated that if we clicked on the shortcut the first time the application ran, the shortcut would be virtualized with the rest of the program and would go away. While this worked on subsequent machines that we tested, we can see how stray shortcuts might lead to help desk calls. Therefore, we encourage Altiris officials to more actively track shortcuts to virtualized applications.

The default action for VSP applications is to shut down and deactivate when Windows closes. There is a handy option that starts all VSP layers when Windows starts. This also starts all VSPd applications, with no further action required than turning on the machine and booting up normally.

In this version of SVS, only the activate and deactivate functions can be delegated to reduced-privilege users. Local administrator users have more latitude, including the ability to delete layers.

Next Page: But SVS isnt without its faults.

Cameron Sturdevant Cameron Sturdevant has been with the Labs since 1997, and before that paid his IT management dues at a software publishing firm working with several Fortune 100 companies. Cameron also spent two years with a database development firm, integrating applications with mainframe legacy programs. Cameron's areas of expertise include virtual and physical IT infrastructure, cloud computing, enterprise networking and mobility, with a focus on Android in the enterprise. In addition to reviews, Cameron has covered monolithic enterprise management systems throughout their lifecycles, providing the eWEEK reader with all-important history and context. Cameron takes special care in cultivating his IT manager contacts, to ensure that his reviews and analysis are grounded in real-world concern. Cameron is a regular speaker at Ziff-Davis Enterprise online and face-to-face events. Follow Cameron on Twitter at csturdevant, or reach him by email at csturdevant@eweek.com.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel