Altiris Software Virtualisation Solution 2.1

Installing and maintaining software is a trying business. Software patching always carries the risk of making something unstable. Upgrading a user to a newer version often means training needs to be given. Installing new software is its own risks such as incompatibilities with existing products or in the worse case scenario, preventing existing products from running.

One solution to the upgrade problem is to give the users a small period of overlap so that they can continue working with existing products while learning the new version. This only works where both versions can exist on the same computer and when you can be certain that uninstalling the old version later, will not cause problems with the new version.

One solution that IT departments have looked at is using virtual machines (VMs) to run different software products. While fine in principal it does require more resources on the local machine. The learning curve is much sharper than normal as the user now needs to understand how to work with multiple VMs and move data between them. This is one of the reasons why VM technology tends to be used mainly in the datacentre, by developers or by IT departments rather than users.

The principles of virtualisation, however, can still be used without the overhead of multiple VMs. Both Microsoft and Altiris have virtualisation solutions that work at the application rather than the operating system level.

With the recent release of Altiris Software Virtualisation Solution (SVS) 2.1, we took a close look at how this technology works and what it means for users and support teams.

Like many companies, Altiris has shifted to a web delivery model where you download the code as a trial and then purchase your licence key. Manuals are available from the Altiris website and Altiris has a separate SVS community site called Juice.

Having downloaded the code and acquired our licence key we started the installation. There are several prerequisites for SVS depending on how you intend to use it. These come in the form of other Altiris products but all is not lost. When you start the installation, if the prerequisites are not there, the installer appears to get them for you.

Running the installation utility immediately required another web connection while it downloaded the full set of code. This was relatively quick and it then unpacked the code and launched the main installer.

The first thing that the installer does is check your machine to see if it meets the installation requirements. If not, it will either give a warning or refuse to continue, depending on the severity of the failure.

An example of a severe problem is remote desktops. Many administrators use remote desktops to connect to their servers. If installing SVS via a remote desktop you must start it via the command line. If you do not, the installer will refuse to run.

One of the unexpected problems during install was the sudden demand of the installer for SQL Server. This was not one of the things that the installer checked for. As it is a prerequisite it would have helped if it were in the installation notes or discovered beforehand. We did try and point it at other databases that were present but it was SQL Server or nothing.

Once we had installed SQL Server we were able to proceed with the installation which eventually completed.

Once SVS 2.1 is installed, the most labour intensive tasks are deploying the agents (a one-off) and creating the Virtual Software Archive (VSA) files. These are the software packages that you will deploy to the client computers. In principal SVA are simple to create. You install the package onto a computer, capture the process and the files, wrap it up and deploy it.

The reality is a little more complicated but, to give Altiris credit, not much more complicated. It's more about developing a process and approach that will ensure that you can deliver packages consistently. Anyone who has created deployment packages in Wise or Installshield, who has written their own MSI files, built Citrix packages or used products such as Ghost will understand how hard this can be if you do not use lots of small steps.

That is the key here, small steps along with a sample computer that allows you to replicate what you have done. Unlike other solutions however, that require you to have all your production systems mirror the reference computer or holds large numbers of reference computers, you are not tied to hardware elements.

All you need to do is install the SVS Agent and SVS Admin tool on the base computer and you can begin to capture software installations and package them into VSA files. Be careful. For best practice consider imaging your underlying OS and reinstalling it before every VSA capture. This ensures that there can be no issues over existing software and the application is installed fully.

The only problem we found with this approach was licensing the Altiris tools, so we quickly changed our base image to include the Altiris tools and the problem went away. We were also successful in doing VSA creation in a virtual machine which was a big bonus as it allowed us to create a single base VM and just copy it back when needed.

So just how easy was it to capture an application? Frighteningly easy! There are just 10 steps to capturing an application although the time taken to install the application still has to be factored in. You can keep the capture file running so that any configuration that needs to be done to the application, even if that means running the application, can be captured. This makes these settings inviolate as they are stored read-only. If you want to give the users control over how they configure their application let them configure it once they have it installed as a layer.

Deploying an application was equally easy. Applications are seen by the SVS agent as layers. You can export your VSA files to the network or make VSA files available through the Altiris Notification Server.

That is it. Finished. Application deployable to any machine with the SVS Agent installed. All a user needs to do is import the VSA file and then activate the layer. It really is so simple that a 10-year-old can use it to install Microsoft Office. When you no longer want the layer, you can deactivate the layer.

One of the big issues with software is handling regular updates, particular Microsoft products where critical security updates are often pushed to the desktop without extra testing. To prevent breaking any VSA file you should turn off automatic updates but then institute a patch process.

The patch process will load the master layer, import the patches and then save as a new VSA file. This way the patches are saved in the read-only area of the VSA file and not in the user area. The problem with them being in the user area is that activating and deactivating layers will clean up this space.

One of the really cool things added with SVS 2.1 is something called the SVS Logon Hook. This allows you to script what happens to layers when a user logs on or off. The big advantage of this is where shared computers are deployed such as in a hot desk environment.

As each user logs on/off you simply configure their applications by turning on/off the application layers. This ensures that no matter where the user goes, they always get their desktop. This has been a real challenge for a lot of companies to date and is why terminal service solutions from Microsoft and Citrix have become popular. Here you no longer have a need to dedicate servers to run applications or build application server farms. The processing is done via the local machine. If the shared computer is a laptop, simply connecting locally will activate the SVS Hook scripts.

There are limitations to the type of applications that you can deploy through VSA files. Anything that has a system driver or software such as anti-virus are not suitable. This is not surprising as the VSA layers sit on top of the underlying OS. Given that the vast amounts of general software are neither of these things, this should not be seen as a reason not to use SVS.

Verdict

SVS seems to be a winner. Operations teams who spend a lot of time deploying and fixing applications can now concentrate on application maintenance rather than application conflict.

Supported operating systems: Windows Vista Windows XP Professional Windows XP Home Edition Windows 2003 Windows 2000 Prerequisites for Software Virtualisation Solution with the Notification Server Platform: Altiris Notification Server 6.0 SP3 R4 or later with the Altiris Agent 6.0 or later installed on client computers Prerequisites for Software Virtualisation Solution with the Deployment Server Platform: Altiris Deployment Solution 6.8 or later with the Deployment Agent installed on client computers SVS also supports using Virtual Software Packages (VSPs) in the following environments: Ardence/Dell SmartClient Hewlett-Packard Consolidated Client Infrastructure (HP CCI) VMware Virtual Desktop Infrastructure (VDI)/IBM Virtual Client Solution