KNOWN ISSUE: Files and folders contained in virtual software layers are remaining after the layers are deactivated or deleted
|Article:TECH29035|||||Created: 2007-04-20|||||Updated: 2007-06-06|||||Article URL http://www.symantec.com/docs/TECH29035|
|NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.|
Files and folders contained in virtual software layers are remaining after the layers are deactivated or deleted. Some of the following symptoms may be noticed:
- Otherwise unexplainable loss of free drive space.
- Intermittent slowness (while files are being copied).
- Incorrect version of executable running.
- Incorrect configuration files being used (because of mismatched versions in the base verse in the layers).
Software Virtualization Solution 2.0, 2.1 Beta
Symantec Client Security 3.5 and above
In Symantec Client Security 3.5, the install path for rtvscan.exe (the scan engine) was changed to %PROGRAMFILES%\Symantec Client Security\Symantec Antivirus\rtvscan.exe. The default ignore list in Software Virtualization Solution does not contain this location. Because the new path is not being ignored, if you are running the 10.1.5 of Symantec AntiVirus contained in Symantec Client Security 3.5, with layers active, when the system is scanned, the files will be copied from the layers onto the base.
To keep the files from being copied to the base when using Symantec AntiVirus in Symantec Client Security 3.5, the following item needs to be added to the Software Virtualization Solution ignore list contained in HKEY_LOCAL_MACHINE\SYSTEM\Altiris\FSL\ProgramIgnoreList:
[_B_]PROGRAMFILES[_E_]\Symantec Client Security\Symantec Antivirus\rtvscan.exe
If you have not made any changes to the default data in this value, the attached .reg file can add this for you. If you have made any changes to the Program Ignore List, you will need to manually copy this new string into the value.
Starting with the release of SVS 2.1 the above value will be added automatically during installation. For SVS 2.1, go to Article 35346 for download locations.
If you have already had files copied to the base because of this issue, do the following to cleanup your file system
- Deactivate all layers.
- Look in the Program Files, Application Data, and Local Settings/Application Data directories for folders and files belonging to applications in layers and delete them. If the virtualized program's main executable is not stored under Program Files, find the directory it is in and remove it from the base. Even if you cannot find all files copied to the base, removing at least the program's executable files from the base will cause the program to only run from the layer and access the files and registry values from the layer.
- If you know what they are, remove any virtualized application specific files for other directories (such as System 32). This will be difficult if not impossible to identify, so be very careful what you delete form these locations.
If you run one of the programs that has been copied to the base, it is possible to also have registry values copied from a layer to the base. It will not be all registry values, but only those modified by a program now running from the base. You can use the layer editor to locate registry values that relate to a layer, but make certain a value is only specific to a certain layer before you remove it. Deleting the wrong registry values can cause a system to become unusable and is not recommended.
It is also possible for files and registry values that should be in one layer to be copied to another layer if a program in the second layer modifies a file or registry value copied to the base. You can use the steps above to clean up you layers, or, since they will be located in the writable sub-layer, a layer RESET will remove these.
As it is impossible to identify all files and registry data copied from a layer because of this, the only sure way to know every thing is clean is to back up sensitive data and re-deploy the computer with a clean image or complete operating system re-install.
|Description||Logged in Littlebuggy (Altiris - Lindon, Plymouth) database|
Article URL http://www.symantec.com/docs/TECH29035