Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Virtualization Community Blog

Group Policy and SVS Layers

Created: 12 Jul 2006 • Updated: 29 Jul 2010 • 8 comments
Adam Hall's picture
0 0 Votes
Login to vote

It is important to remember that SVS layers are still subject to Group Policies, even though the layer may be activated after the application of the policies.

A local cache of the Group Policies are held on the local machine when a member of an Active Directory and remain in force for the duration of the refresh interval.

Local policies are stored locally -- if you ever get into a situation of difficulty i.e. you lock yourself out, simply delete the %systemroot%\System32\GroupPolicy folder (on the system) and log back on.

When you activate a layer, the Windows OS will still enforce the GPO settings, even if you have specified different settings in the layer.

This is important to remember when testing and troubleshooting. Before you go nuts trying to figure out why, take a look at the GPOs to ensure this is not the problem.

Comments 8 CommentsJump to latest comment

Osm3um's picture

A bigger question is can one use AD/GPOs to activate and deactivate centralized applications?

I have this idea that one could create a layer, save it to a DFS volume, and active/deactivate the app via GPO.

Bob

-1
Login to vote
Adam Hall's picture

Given that all actions within SVS can be automated, to achieve this all that is required is a script to import the layer and activate it.

To import ...
svscmd IMPORT -P "\filename.vsa"

To activate ...
svscmd ACTIVATE "LayerName or GUID"

The only challenge I can see is how to check if they layer already exists, and if so, skip the import. This could possibly be done with the enumerate layers option. Or you may want to use the FORCE option to overwrite the layer regardless.

-1
Login to vote
Bo Faurholt's picture

Hi

If you use a script to import layer's using SVSCMD, then an existing layer will NOT be re-imported, unless you use the FORCE option.

So you don't need to check if a layer already exists, SVSCMD handles this for you.

The import will simply be skipped if a
layer already exists.

/Regards
Bo Faurholt

-1
Login to vote
petroc49's picture

Has anyone tried this?

-3
Login to vote
riva11's picture

Yes, it really works well as explained.

Regards,
Paolo

+2
Login to vote
kgmartin365's picture

Some of the applications that we have deployed require changes to the NTFS security. Typically we would send these changes down using GPOs.

We have found that when we do this and apply the NTFS changes to the "\Program Files\" all of the files and folders that are affected are left behind if we deactivate the layer. However, if we set the NTFS permissions on the files and folders under the "fslrdr" folder, then all of the files are removed when the layer is deactivated.

Is this working as designed? Can anyone tell me if they have experienced this behavior as well?

+1
Login to vote
Wm Jesse Foster's picture

The GPO activates a base process to make the security changes. Because of this a copy of the file is made in the base. Best practice would be to make the security changes in the redirect area (fslrdr) before exporting the layer. This way those security settings will be there when the layer is imported on the client machines.

-1
Login to vote
kgmartin365's picture

I figured that was the case, but wanted to make sure.

Any idea if you can apply permissions under the fslrdr folder to the layer itself via GPO?

I figure it could be done, except that it would be difficult to grab the correct hex directory under fslrdr since machines may have different numbers of imported layers.

Any gotchas that you know of if we were to do it that way?

Any easy way you know of to identify the correct directories for the particular layer?

Thanks

+1
Login to vote