New Thinking Behind Prioritizing Layers and Classes

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 design and default behavior of the Fortress file system filter driver -- the foundation of SVS.

Going Forward
Here's what we're doing: Starting in Beta 3, the base takes precedence over active layers in the file/registry search orders. So activating a Virtual Software Package will not create a new conflict with any pre-existing software on the box, nor is there a risk of effectively downgrading a file that may be there as part of a security patch.

Additional Flexibility
We've also added the ability to change this behavior if you need to. Each VSP has two different configurable priorities.

• First is the Layer Priority, which determines where in the search order all objects in the VSP are seen, with the exception of HKEY_CLASSES_ROOT.
• The other is the Classes Priority, which is a separate prioritization of the VSP's registry objects under HKCR. When you have multiple apps on a box that can handle a given file type association, this allows you to configure which one wins, without impacting application compatibility.

If you're using the command line interface, the Layer Priority is called "NORMAL" and the Classes Priority is called "HKCR" -- type "svscmd /?" to get the correct syntax for viewing and changing layer priorities.

Another item worth noting is that the priority is saved in the layer metadata and is transported with the VSP when it is exported.

You can learn more about prioritization in the Reference Guide and in an SVS Architectural White Paper that will be ready by Final Release. This isn't something that customers will typically need to modify -- the default behavior probably accommodates 98% of use cases. But it's there if you need it.

More in the works
That being said, there is still a case for allowing visibility to be configurable. Basically, another priority setting that tells the filter driver to "remove this layer from the search order," so the only processes that can possibly see objects in that VSP are processes running from that VSP. The beauty behind how we architected prioritization in Beta 3 is that additional features like this become almost trivial to add in. We'll definitely be looking at this for the next release.