Managing Data with Virtualized Applications

Software Virtualization Solution (SVS) lets you manage data in three ways: you can do nothing, you can add data layers, or you can use exclude entries. Let's discuss the pros and cons of each option so you can decide the best approach to managing data in your own environment.

Things to Know about Where Data Goes

SVS only hooks local hard drives. In other words, data that is written to local hard drives is redirected to virtual layers. Two of the most commonly asked questions are answered below:

Question: My users put their data on a network drive. How do I configure SVS to write the data to the network drive?

Answer: SVS does not redirect files on external network resources.

Question: I have a USB flash drive | CD burner | other removable device. How do I configure SVS to not write the data to my removable device?

Answer: SVS does not redirect files on removable devices.

Variables

Because SVS uses variables for such items as where Windows or other applications are installed and where user data is stored, the package is portable. Thus, when a Virtual Software Package (VSP) is installed across an environment, you don't need to create a new VSP when you change system or user variables.

The Do Nothing Approach

Pros: Easiest thing in the world to do.
Cons: Resetting an application layer will result in data loss.

This solution is by far the easiest. Unfortunately, however, you lose the big advantage of using virtual applications in the first place-being able to reset applications. If you reset an application, any data in the writeable subsection of the layer gets thrown away and is then lost forever. Evan, our support guy, told me several people have had this problem already. If you call him, he will probably not be very helpful. "Doing nothing" is probably not a good idea.

Use Data Layers

Pros: Easy to back up data, easy to restore data, easy to manage where data goes, all data is in a known location.
Cons: Files written to a client network share are not put into the data layer. If a layer is active, all users can modify or delete the file.

Microsoft Office 2003 associates itself with roughly 150 file types. Do you know all 150 file types Office can modify? I know I don't. Luckily a tool called DLC can help you. DLC looks in an application layer's registry and creates capture items for all the files types that the application registered. Read the documentation on DLC for more detailed information, If you have already been using DLC, check it out again as it has been upgraded. DLC takes the pain out of figuring out which file types are associated with a particular application. With the right tools, managing data with data layers can be quite easy.

After running DLC for Adobe Reader, this is the list of file associations that were captured. The Data Capture tab is located under application properties in SVSAdmin.

If all the data is in a data layer, you can archive the data layer to a .VSA file at any time and import the data if it gets lost. If you use DLC to create the data layer, you can have an high level of confidence that the application will not put any data into the application layer; if a problem does occur, you will be able to reset the application layer without loss of data.

Even if you use data layers to manage your data, you will probably need to use a few excludes to fine tune your data management. For example, drives other than the system drive are not very portable, and what is the point of having another hard drive if no data is really put on it, so you may want to add exclude entries for all other hard drives. I personally find the data layer approach easy to manage and implement. I use this approach on my computer at home and at work. But, then again, I'm just a single college student.

Exclude Entries

Pros: All data is on the base. Data acts like it did before SVS was installed. Data is associated with the user.
Cons: All data is on the base. You lose the advantages of managing with data layers. It is slightly more difficult to manage the exclude entries.

After DLC was released, I received several requests for a tool that would add exclude entries to an application layer so the data would go to the base and not to the application layer or a data layer. I actually considered creating this tool when I created DLC, but I decided that doing so would create a problem with managing data through exclude entries. Let us have a look at a simple example.

I am a computer programmer and have Visual Studio in a layer. I add exclude entries to the Visual Studio layer for all the data types. I do not like all of the bloat in Visual Studio so, for most of my programming needs, I use Crimson Editor. Unfortunately, Crimson Editor does not associate itself with any data types. What do I do? If I edit a file with Crimson Editor, all the data will go to Crimson's writeable sublayer. Hence, when I think of managing through exclusions, I think,

"Exclude Here,
Exclude There,
Exclude Everywhere!"

To make sure all data is written to the base, you need to do a couple of things. First, you need to make sure that no data layers will accept the file types that you want to be written to the base. Of course, since you are trying to manage data through exclude entries, you probably won't have any data layers. Next, you need to add an exclude entry for every application layer. This may sound easy, but it requires diligence to make sure that the exclude entries are up do date.

What happens if you add a new application -- would you need to redistribute all the applications again with updated exclude entries? I hope you can see the nightmare that is in store. Don't worry, though let me introduce you to ExcludeGen and ExcludeCopy. These two command line tools will help you avoid the nightmare.

ExcludeGen  <templateLayerName|GUID> <applicationLayerNames|GUID>  [FLAGS]
ExcludeCopy <templateLayerName|GUID> <applicationLayerNames|GUID>  [FLAGS]

See the documentation on these tools for more information.

After running the Exclude utilities for Adobe Reader, this list of file associations are added to the Exclude Entries for the Data Layer. The Exclude Entries tab is located under the application properties in SVSAdmin.

A template layer is an application layer with nothing but exclude entries. A template layer has two advantages: the application layer is small, which decreases the amount of network traffic, and you can use SVS Admin to manually edit the layer.

ExcludeGen looks in the registry of an application layer and generates exclude entries for all of the file types that the application registered, and puts the exclude entries in the template layer. You will need to run ExcludeGen for every application layer on your computer. You can pass the same template layer multiple times to get an aggregate of all the data files. You can also add directory excludes manually. When all of your exclude entries have been contained in a single location, you can package your template layer in a .VSA file and send it to all your client machines.

Once the template layer is on your client machines, you need to apply the exclude entries to all the application layers on the client. ExcludeCopy is here to help you out. SVS does not allow you to modify active layers, so ExcludeCopy requires the application layer to be deactivated. You can pass ExcludeCopy the -F flag to deactivate the application layer, copy the exclude entries, and then reactivate the layer. If the layer is already inactive, ExcludeCopy will just copy the exclude entries to the application layer.

Exclude entries are another good way to manage data. However, using exclude entries is a little more complex and requires more diligence. Also, each of your client computers has an extra layer. You will probably want to name your template layer with some type of flag like TEMPLATE_DO_NOT_ACTIVATE, so you do not forget what it is for.

Here is a simple scenario. You have been diligent in applying exclude entries everywhere. It is easy with ExcludeGen and ExcludeCopy. You decide you want to distribute Apache 2 in a software package. Apache 2 is not officially supported, but it seems to work for me. You want to install PHP, so you modify Apache's config file with Notepad. When you start Apache, you discover that Apache runs as though you had not modified the config file. What's going on? Well, you used Notepad, which is an external application, to modify the config file. SVS made a copy of the config file on the base, that is the file you edited. However, the config file in the Apache layer, which hasn't been modified, has precedence and is the file that gets opened by Apache. You can fix this by creating a data layer and putting the config file in the data layer. Because data layers take precedence over application layers, you will then be able to edit the file normally.

I recommend that you create a master template with all the exclude entries you need to apply to all the application layers. In most cases, this is like wrapping a person up like a mummy when all they have is a paper cut. You can also use ExcludeGen and ExcludeCopy for a more granular approach. You should use whatever approach keeps your data safe and sound.

Conclusion

Managing data with virtualized applications is new. If not done correctly, you can lose data and time. With SVS, you have three options. The first option, doing nothing, is not a valid solution for anyone. The next option, implementing data layers, is easy to set up and administer. The third option, using exclude entries, is a little more complicated and harder to administer. Luckily, tools like DLC, ExcludeGen, and ExcludeCopy can help you manage your data and still get home in time for dinner.