Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.
Endpoint Virtualization Community Blog
Showing posts tagged with Configuring
Showing posts in English
Brian Mann | 07 Feb 2006 | 0 comments

What happens if you create data layers on your computer's E drive and you make the move to a computer that doesn't have a E drive in its path scheme? SVS tester Brian Mann explains how to get yourself out of this pinch.

Evan Thomas shared some good advice about how and where to create layers in his "Saving Files in a Virtual World; Do You C:\ What You're Doing?" tip. If, however, you didn't read his tip until now, here's how to avoid one of the pitfalls he describes.

If you set up your layers on a machine with an E drive and you've been moved to a machine without an E drive, don't worry, your files are still saved in the layer. In order to get to the data, deactivate the layer and double click on it.

click to view

This will open the advanced layer editor. While...

Jeremy_Hurren | 31 Jan 2006 | 0 comments

You can adjust the level of compression that SVS applies when it creates a Virtual Software Archive (VSA). By adjusting this level, you can find a balance between performance and size. Jeremy Hurren shows us how to find the perfect balance.

If you have data that needs a different level of compression, you'll be happy to know there's a way you can change that (either per-layer or machine-wide). A perfect candidate would be my MP3 data layer which holds many gigabytes of data. Since the compression on MP3 files is infinitesimal, I choose to have them simply stored and not compressed at all to speed up the process.

The following setting will set the compression level machine-wide:


CompressionLevel (DWORD) = 0-19 (5 is the default)

To set this for an individual layer, place the value under the following registry key:


(replace 1 with the...

Jared Payne | 31 Jan 2006 | 4 comments

The ability to apply a virtual patch to a software application is one of the exciting features we've been told to look forward to in a future version of SVS. Jared Payne has found a way to get this functionality today ... and he's given us the steps!

The ability to apply a virtual patch to a software application is one of the exciting features we've been told to look forward to in a future version of SVS. Here a few steps that will allow you to apply virtual patches using today's SVS.

  1. Start with an application installed to an SVS application layer.
  2. Reset the layer to make sure it is clean.
  3. Activate the layer.
  4. Run the application's update feature (do not enter capture mode).
  5. Create an empty layer (for this example, we'll name the layer "App_PATCH_1").
  6. Run WriteableSwap.
    WriteableSwap application App_Patch_1 -F
  7. Export App_Patch_1
  8. Send App_Patch_1 to all your client...
Scott Jones | 24 Jan 2006 | 0 comments

SVS Product Manager Scott Jones explains how prioritization of layers and classes came to be and how this added functionality can be useful to you.

One of our SVS beta testers posted a suggestion in the support forums that has influenced our development plans. I wanted to take the time to explain the suggestion and what our engineers are doing to implement it. Here's the post:

"Having the ability to layer applications is great, but it would be beneficial to have a switch that would change a package to run totally isolated/virtualized from other applications on the machine. Isolated packages would allow for quicker deploy, reduced testing, and a high level of confidence the activation would not cause an issue on the system."

This request (and others like it) was one of the key driving factors in our decision to take a step back after Beta 2 and reconsider the...

BBishop | 13 Jan 2006 | 0 comments

We asked troubleshooter Brent Bishop to share a swig of wisdom related to Notification Server and SVS working as a team. He shares a few ways to sidestep problems you may run into if Notification Server fails to recognize SVS or execute its commands.

The Issue

Software Virtualization Solution (SVS) advertisements which run the autogenerated programs inside of Notification Server (NS) SVS packages (there are 15 programs autogenerated at this time when the *.vsa file is selected in the Package Manager window or the Virtual Software Wizard) fail to run and give an error message of "SVSCMD.exe is not recognized as an internal or external command, operable program or batch file." or they simply seem to fail to perform their function.

The Details

This may occur on all or only some NS clients running SVS. It generally will not occur shortly after the SVS agent is installed as the path statement should still be in order. But other installs or user changes...

Jeremy_Hurren | 09 Jan 2006 | 5 comments

SVS developer Jeremy Hurren tells us how to tune a few settings to help applications shut down gracefully -- especially useful in a virtualized world where "deactivate" does more than simply close an app.

It's possible with SVS to deactivate a layer that is home to an application that is currently running. When you do this (deactivate the layer) the running application, by default, displays an error message that informs you that an application is running and asks if you want to (forcefully) shut it down. If you say "yes", the application process is terminated. This can leave undesirable results such as unsaved documents and icons remaining in the system tray.

You can specify a registry key that will cause the Software Virtualization Agent to automatically (and gracefully) shut down an application when a layer is deactivated. If, for example, you are running Microsoft Word and have made the registry changes noted below, when you attempt to deactivate the Word layer you...

BBishop | 22 Dec 2005 | 0 comments

Technical wizard Brent Bishop sheds some light on an inventory problem caused by invalid characters in application layer names. The juicy truth is that SVS is still being tuned to speak perfect XML -- the language spoken by the inventory engine in Notification Server.

The Issue

Here's a problem that raises its ugly head when a Software Virtualization layer inventory does not appear in Notification Server (or does not appear to be complete).

The Details

As layers are imported into SVS on a NS Agent machine, application information is inventoried to the NS server that the NS agent reports to. There is currently an issue with missing or incomplete inventories being reported to the Notification Server.

The Cause and Resolution

SVS does not properly escape some characters for XML. So if the following characters are used in the name of an SVS layer, the layer inventory data becomes inaccurate or missing.

quote (")

BBishop | 12 Dec 2005 | 0 comments

Tech guy Brent Bishop explains why it's import to remember the all-important reboot step after you install SVS.

The Issue

If you've just installed the Software Virtualization Admin (SVS Admin) tool and it allows the import of VSA (Virtual Software Application) files but will not activate them, read on. Oh, yeah, to keep you scratching your head, no message boxes or error messages accompany the odd behavior.

The Details

You've just installed and can run the SVS Admin tool. All seems well until you activate an application layer.

The Cause and Resolution

Here's the Juice: SVS must be rebooted before the file system filter driver (which is at the core of SVS functionality) will operate. A logoff/logon will recache the local security credentials so that the SVS Admin tool can be run but this does not make the SVS filter driver fully operational. A reboot after install of SVS is necessary to get everything running as designed.

Admin | 14 Nov 2005 | 7 comments

Chris asked: Can we tie the activation of a layer to the logged-in user? As an example, a layer (say Project) exists on a PC, and if I log in, it gets activated, but if you log in it does not.

Hi Chris. Today, what you've described can be done with login scripts. We have several beta customers who are doing just that. Eventually, we'll natively expose packages based on who is logged in (including on multi-user machines such as Citrix).

The_Snave | 14 Nov 2005 | 1 comment

Want to keep your network lean and mean? Altiris product specialist Evan Thomas tells us where to store Virtual Software Applications (VSAs) to minimize network traffic.

When using SVS in the Notification Server console, the VSA files should be stored in their own folders, not in a general "VSA" folder. The reason for this is that SVS uses the same delivery mechanism as Software Delivery. Software Delivery doesn't send one specific file, it sends EVERYTHING in the folder.

click to view

Bad way.
If you have all of your VSA files stored in one central location and you create a policy in Notification Server to Import "Firefox 1.0.7.vsa", the delivery mechanism will copy ALL files in the VSA folder, but import just the Firefox VSA file.