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

VSA's behaviour with User data and Roaming Profiles

Created: 31 Jul 2011 | 2 comments

Hello.

I have searched those forums extensively, but I'm not able to find satisfactory answer to my questions. I found some vague information in this older thread, and Im wondering whether there have been any developments. A note on the configuration that we are running here, it's Windows 7 VMware based VDI's.

As an example I'll use application called "Putty", which illustrates the problem well. I have done this test and it is repetable every time. So the issue we are having is as follows:

1. Application layer (.vsa) is created and inported to a test desktop.

2. User created a session profile, called say "test01" which basically means that HKCU registry heys/settings are created that are storing hostname "test01". Then user logs off. At this point Layed is active. HKCU settings are saved into roaming profile.

3. Same user logs on to the same desktop. At login the layers are not activated - they are activated after login via a custom system (this is done to speed up login process). Roaming profile restores HKCP settings. But because layer(s) are not active, it restores those settings into the base registry.

4. user layer(s) are activated, including Putty layer (along with it's virtual HKCU registry keys). So not where's a conflict. Base registry settings are the same as Layer putty settings. This is not a conflict as such because at this point they are identical, but two distinct sets of registry entries exsist - onein base and one in layer.

5. The real issue occurs if at this point user changes the settings, for example for the Putty session to point to hostname "test02". Now there is a conflict because the base setting is "test01" and the layer setting is "test02". So the layered Putty reads the layer setting "test02" while at logoff, roaming profile will pickup "test01" from the base setting - this is because in case of conflict layered app reads the layer setting while OS/apps outside layer read the base setting (am I correct in this statement ?)

6. So now when user logs on another desktop, where Putty layer does not have user's own settings, roaming profile will restore the "test01" setting (which is incorrect by the way), while because it's different desktop with another copy of the same layer, Putty layer might have different settings altogether.

So the result is that the HKCU entries from the layer's will not "roam" correctly. I presume same behavior would apply the User's AppData files.

This is a peculiar situation which occurs because during login, when roaming profile is restoring HKCU settings, user dependent layers are not activated. Again, in the environment here, layers are activated right after user logon process completes, this is done to speed up logon process. Otherwise activating sometimes 20 layers would significantly affect login times, so that solution would not be popular here with users and managment.

Another solution I see, is to setup global exclusion to HKCU and and user's AppData, so that all the user settings are always saved to base, but I suspect this might create issues with some application layers, and applications refusing to run, etc.

Is there any other way around this issue ? Maybe some other way to provision saving/restoring of user settings into the roaming profile or otherwise externally, and making it portable so these can be imported to another layer on machine at logon or layer activation time, or some other arrangment ?

Thanks in advance,

Matthew Kaminski.

Comments 2 CommentsJump to latest comment

MikeWoodd's picture

Hey Matt, I don't have a solution. :) Maybe MORRRRRE BOOOOST will help.

I do know, the new version of SWV (6.1 SP7) is faster and affects login times a lot less.

I'll trade you - I also know there is a peculiar bug - 

Layer has a USER_TEMPLATE registry keys that contain to (HKCU)\Software\Classes\CLSID\...

Layer is Active at user login

Layer RO USER_TEMPLATE is cloned to layer RW, and registry keys created in the layer RW fail to inherit permissions properly, such that non-admin user only has Read permissions to HKCU\Software\Classes\CLSID

The application that needs the CLSID keys works;

Applications that try to write to HKCU\Software\Classes\CLSID fail.

The case in point - Outlook,  2007 trying to load up a Custom Form from the Org Forms Library, and pops with an OLE error message - it's trying to registry the form under HKCU\Software\Classes\CLSID but can't because the "user profile" (composite base registry and layer keys) CLSID key only has Read permissions for the user. The user account is missing (not "inherited" correctly) from the ACL on the reg key.

This ONLY happens when the layer is already active before the user logs in. When the layer is inactive,  then activated while the user is logged in, the layer RW CLSID keys ACLS are "inherited" correctly.

Later dude :)

Mike

Palvaran's picture

We were never able to make that work in our AD Environment either.  We use a combination of Application Data Redirection and Roaming Profiles, but because of the inability of users to access the layers, it would cause the dreaded blue screen with the mouse pointer.

Our workaround was to put a group policy loopback that would force users to not use redirection or roaming profiles in the machines in certain OUs.  That way when they are on their machine in their office working it saves settings, but it would not follow them to say, a classroom or lab.

Systems Administrator
Rice University

Remember, "The happiness of your life, depends on the quality of your thoughts."