AppVolume redirect personalisation

[danielkrause]

Hi guys,

we like to redirect the personalisation of a appvolume application to an external fileserver or UserHomeDirectory.

Any suggestions how to realise that?

[mellicott]

Where are the personalisation files stored at the moment?  Can you change an option in the application to point somewhere else?

Are you using UEM?

[danielkrause]

We are using appsense for personalisation.

Files a stored in the local %appdata% directory.

Writeables will cause a temporary profile.

We are looking for a Independent solution for the personalisation.

[Ray_handels]

For the record, writables DONT create a temp profile, if you do see this happening there is something wrong with your configuration.

The writable volume holds a local profile. When logging in the appvolumes agent checks to see if there already is a local profile for the user logging in and if so, removes it. Then it attaches the writable volume creating a local profile in Windows and then, after the writable volume has been attached, releases the logon process, giving you a local profile.

We use a tool called Scense LifeProfiles (which is soemthing like Appsense) and it simply copies the information from the profile as it is were a "normal"  machine. Appsense should work correctly with it's personalisation. One thing i heard though is that there are some issues performancewise with Appvolumes and Appsense, haven't tested it myself though.

[Mark808]

I'm rolling out AppVol 2.11 and UEM 9 in a non-persistent Win 10 desktop environment. 

Is there a recommended way to handle the user profiles i this type of configuration?

I can use a writablevolume for everything, but they are seem challenging to backup on a regular basis and I would rather not keep user files in the writablevolume.   Standard Windows Roaming User Profiles and UEM redirection for the user files (my Documents, etc.) would work, but there is the whole "delay at login until the whole Roaming profile is loaded" thing I would rather avoid if possible.  I unsuccessfully tried to use a writablevolume to store the user profile settings (absent a MS Roaming-Profile) but it breaks UEM redirect of the user folders (My Documents, etc) and places these files in the writable volume.

How are others configuring their systems?

[Smoke14]

I would redirect the users folders to a Home Share. I would configure all user profile management through UEM, if your environment and policies allow it.

Check out some of my other posts, they should help you make a decision.

[Mark808]

Thanks Mike,

I tried doing exactly that, but I haven't figured out how to capture the Local Registry settings and User/AppData/Local settings without using a writablevolume.  But once a writablevolume is used, all the UEM folder redirects appear to be ignored. 

I'll check out your other posts. Perhaps you addressed this already in one of those.

-Mark

[Ray_handels]

Hey Mark,

You could also set up redirection of My Documents, Desktop and downloads using a Windows GPO. We use folder redirection in combination with a writable volume and it works like a charm.

Also please keep in mind NOT to use a roaming profile whenusing writable volumes. The writable volume holds the local profile in it and merges it into the filesystem before login of Windows is being triggered.

And for as far as I can see there is no other way than to use writable volumes if you would like to store LocalAppdata in your "profile".

The other option to not have a user safe data in the writable volume is to not give him administrative priviliges, that way you can set permissions on folders so that users can accidentally save data on a local drive (or hide the C drive using a Windows policy).

[Smoke14]

I don't like WV, I try to stay away from them, when using UEM.

If am reading your last statement correctly, you need to enable and configure 'Windows Settings' to monitor your users APPDATA. For example, something like this;

They are REM out here, but this shows you how to monitor and save the changes at log-off and apply them back at logon.