Hide SVS Against Editing

More pros, plus the limitations of obscuring the redirect areas. You need to know all before deciding whether to do this:

Pros:

• Prevents inventory scanners from hitting on virtualized apps twice (see this).
• Prevents self-healing shortcuts (esp. Quick Launch shortcuts) from getting "fixed up" by Windows when the app's layer is inactive. By "fixed up" I mean the target gets altered to point to the real path instead of the virtual and you end up running the app (or at least trying to) from the redirect area. Result: either the app breaks, or if it does run it runs as if from the base so is effectively not virtualized.

For these two reason, obscuring the redirect area is usually a best practice. However...

Limitations:

• Only works for the default redirect areas (usually c:\fslrdr and HKLM\SOFTWARE\fslrdr, or as specified during SVS Agent install). So when you have multiple redirect areas, all the non-default ones will be visible.
• The purpose of Obscure Redirect Areas is to achieve the benefits above (and esp. the one Frank listed -- to keep nosey users from seeing it and getting curious!). But it is not a security feature. Even when the redirect areas are obscured, users still have their normal Windows permissions for objects (files or reg. values) in the redirect areas and can still access them directly if they know the full path and object name.
• Can be an annoyance for technicians trying to troubleshoot a layer problem locally on a client. If they want to switch the setting, they have to reboot and then remember to switch it back before handing the machine back to the end user.

Scott Jones
Technical Product Manager
Symantec Endpoint Virtualization

Same problem from 2 years ago.

http://juice.altiris.com/tech-tip/342/how-to-deal-...