This is another post in my series about application virtualization. More than a year ago Symantec bought Altiris, a vendor well known for systems management. I was quite surprised when I heard about the deal because the look and feel of Altiris products is somewhat different from Symantec solutions. This also applies to Altiris’ Software Virtualization Solution (SVS). I tested the tool and have shared some of my insights in this post.
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
- Automatically mount an NVMe EBS volume in an EC2 Linux instance using fstab - Mon, Feb 21 2022
I encountered the first problem when I wanted to download SVS. The download page showed four different file names which all sounded quite similar: Software Virtualization Solution 2.1 Logon Hook, Software Virtualization Solution 2.1 SP1 Integrated Installation, Software Virtualization Solution 2.1 SP1, and Software Virtualization Solution 2.1 SP1 Professional. There is a short note which is supposed to clarify what those product names mean, but I must admit I didn’t really understand it, so I downloaded the professional version.
It took me a while to figure out that this package doesn’t contain the Altiris Software Virtualization Solution, but only Symantec’s application streaming product. It is an independent tool which can be used to stream conventional applications and SVS apps as well. I will probably discuss this tool in another post. “Software Virtualization Solution 2.1 SP1 Integrated Installation” contains the so-called Notification Server which is for deploying SVS apps. I am not sure if this installation package also contains the software virtualization solution itself, though. Its setup requires you to install an SQL Server first, so I postponed my investigation to another time. Lastly, the Logon Hook tool is for triggering SVS actions based on Windows logon and logoff events. Thus, if you are only interested in Symantec’s application virtualization solution, you should just download “Software Virtualization 2.1 SP1.”
When I first launched the SVS Admin, the SVS GUI, I was quite surprised at how simple this tool is. Testing SVS was easier and less time-consuming than downloading it. First, one has to create a so-called Virtual Layer, i.e. the virtual environment. A Layer can contain an application or just data. Creating an Application Layer is fairly easy. You just have to launch the setup file of your application and the SVS Admin will capture all changes the installation routine is trying to make to the system. Unlike Xenocode, SVS doesn’t compare the system states before and after the installation, but intercepts the write accesses of the setup.
To use the virtualized application, one has to activate the Layer first. This doesn’t launch the application, though. Activating a Layer means making an application available. All system changes made by the setup routine will then be visible, i.e., icons, registry changes, the program folder, etc. For example, I virtualized 7-Zip, a file archiving tool. 7-Zip makes changes to the Windows Explorer shell, which allows for launching the tool from an Explorer context menu. When I activated the 7-Zip Layer, its Explorer context menu entries became visible instantly.
Layers can be modified with the SVS Admin and also during runtime. For instance, if you save a file from a virtualized application to a Windows folder, SVS will redirect all write accesses to the virtual environment. If you deactivate the Layer, this file will just disappear no matter to which folder you saved it. However, it is possible to configure so-called Global Excludes. If you save a file to a folder that belongs to the Global Excludes, SVS won’t redirect it. Global Excludes apply to all Layers, but it is also possible to configure specific excludes for each Layer separately.
I’ve already mentioned above that SVS supports not only application Layers, but also data Layers. A data Layer virtualizes a certain folder or a certain file type. For example, you can virtualize all .doc files this way. If you create a .doc file while this Layer is active, it will be redirected to the virtual environment. Deactivating the Layer will make those .doc files disappear. .doc files that have been created while the Layer is not active will stay, though. A data Layer that virtualizes a certain folder works the same way. For instance, you can virtualize the My Documents folder. All files that you create in this folder while the Layer is active will disappear whenever you deactivate the Layer and will show up again as soon as you reactivate the Layer. Files in the My Documents folder that are created while the Layer is deactivated are not affected.
This Layer concept is certainly quite interesting. It has just one disadvantage. You can’t create a portable executable file which contains the complete virtualized application. This means you can’t store SVS apps on a USB stick, for example. To launch an SVS app on another computer, you have to export the Layer to a Virtual Solution Archive (VSA) first. After you’ve installed the SVS agent on the second PC, you can import the archive and activate it there. This can be done with SVS admin, but in a corporate environment you probably won’t let end users do this.
Subscribe to 4sysops newsletter!
SVS comes with a command line tool for this purpose (SVScmd.exe). This allows you to mange SVS apps with scripts. However, you have to install the SVS agent first on all your computers with a software deployment solution. Symantec also offers three other solutions to remotely manage SVS, though. I will probably discuss these soon.