Login to participate
Endpoint Management & Virtualization ArticlesRSS

SVS Packaging Best Practices, Part 4: Exclusions

erikw's picture

There is a very easy solutions. Global exclusions! But if you don't understand SVS this is also a difficult to understand option. In this article I'll tell you everything you need to know about Exclusions, how to deal with them. And most important, how to set them correctly for your environment.

There are two kinds of exclusions:

  • The first is the Global Exclusions that can be set on a global or a per layer base.
  • The second one is the Extension Exclusion.

In this article you will find both exclusions explained.

During the installation of SVS, there are already two exclusions set. These are the most common, and I advise you to get them set.

  • The first one is the exclusion for [PERSONAL]:
    • This one prevents all documents and settings for the c:\documents and settings directory to vanish inside layers.
  • The second one is the exclusion for [DESKTOP]:
    • This one protects everything on the desktop to vanish into the layers.

Now you have to setup extra exclusions for your pc or environment.

First, decide where you wish to save your data. If you save it to the c:\ with a self created folder, then you have to designate that one as an exclusion. Please remember to mark the button "include subdirectories".

If you save data to the d:\ drive, then it is a common practice to set that as a global exclusion, including again the tab "Include subdirectories".

Do you save data to the network on a drive mapping, then you do not have to setup anything. Data stored on network drives is always protected. SVS cannot store data from network drives inside layers.

So, that was easy! Or not?

No, it is not easy. You have to remember that there will always be exceptions. For some applications, you do not want an exclusion at all. All data touched from that layer should be in the layer. This is common practice with internet browsers like firefox. It will protect your system from lots of dangers on the internet. It will not stop a virus or a worm, but it will stop malware.

How do you override these exclusions?

When you de-activate the layer, just double click on the layer. Then go to the exclusions tab and mark the button: Ignore Global Exclusions.

Wow. That is easy. In this tab, you can also set particular exclusions for this layer only. Just create them. In the top screen you can also add extensions. So if you have virtualized Office, and set a global exclusion on your data directory, but you wish to store xls files inside the layer, you can build an exclusion for the extension xls. This overrides the other global exclusions.

WARNING: Data that is stored inside the layer will get destroyed when you reset the layer!

Hey, I have an idea! I set c:\ (Root drive) as a global exclusion, and then I mark the tab "include subdirectories". At that moment you will notice that not only all data, but also all files will stay resident after de-activating the layer. The files will not magically disappear in c:\program files.

Are they still virtualized, or are they now local? They are still virtualized, but will not disappear. This behavior can cause some unpredictable errors. If you start a shortcut on the desktop, normally the application will start if the layer is activated, or will give an error if the application is de-activated. When you set a global exclusion on c:\ instead of the error "application can't be found", you now get a message to search for the executable. This is something you really do not want.

You will notice that there is no way to set global exclusions for the registry. In a future article I will explain how to prevent losing certain registry keys when resetting an application.

Here is a list of DOs and DON'Ts in Global exclusions:

DOs:

  • Protect your data in c:\Documents and Settings.
  • Protect your data on the desktop.
  • Protect a particular folder on c:\ when you store files there.
  • Protect other drive letters from different partitions or hard disks in your system.
  • ALWAYS'S remember the button "include subdirectories"

DON'Ts:

  • Don't set c:\ as a global exclusion!
  • Don't attempt to set an exclusion for filenames called: DAT, D0A (yes, it is a zero), and never, and I really mean NEVER, set a exclusion for the extension SYS.

    This will destroy your system after three or four reboots. There is a pagefile.sys and on portables a hibernate.sys that will stay resident inside layers when you do this, and they are always's in use. If you set an exclusion for the extension .sys, these will get inside your layer, and your hard disk will crash after a couple of reboots.

    Windows will become unpredictable, and you will be very disappointed in a very great tool named SVS.

But wait! There is more to know!

If you use SVS on a terminal server with the additional tool DVS4SBC, then there are some additional things that you should know.

  • Don't include [DESKTOP]in a global exclusion.
  • Don't include [PERSONAL] in a global exclusion. On terminal server it is common practice to save the profile on a home share. The data will get to an UNC path or a drive mapping and this does not need an exclusion.
  • It is also common practice to delete local user profiles after the user logs off. But in this case you will store the profile inside a layer, and it will stay resident. If a user logs on to a different terminal server and changes settings, they will conflict with the profile on the other terminal servers.
  • Instead, a very good tip if you use DVS4SBC is to delete all Exclusions.
  • DVS4SBC has its own way to save files and registry key's before resetting a layer.

    This tool will be available to all DVS (on a local system) and DVS4SBC (on a terminal server or Citrix server) users in July. The tool is called DVSExcluder.

     

SVS Packaging Best Practices, Part 3: Update Existing Layer

SVS Best Practices, Part 5: Restoring a Crashed PC

Pascal.KOTTE's picture

Nice - Registry exclusion vs Regitry protection

I will track what you talk regarding "registry exclusion". But in fact, we need more often a "registry locking" feature. To get any "exclusion" of registry overwriting (ok normally just change ACL, but try doing this those local admin users...) ;-)
~~~PaKo

~~PaKo @ www.BeMore.ch (Sorry for the Bad English, did you speak French ? Join us https://www-secure.symantec.com/connect/groups/gro... )