Just what the heck is a "shared pool of persistent VDI"? If the same image is shared, you should want it cleaned between users or you are setting yourself up for lots of problems over time. A shared pool of VDI should always be non-persistent.
A pool of cloned Citrix Servers should also clear out local profiles upon logout to prevent crud creep.
But these are standard deployment issues, not specific to App-V. App-V just assumes that you would follow generally accepted practices.
Thanks for the reply...
Clearing the local profile might be standard for a non-persistent VDI, but not for a desktop or persistent VDI as far as I know?
If the tool requires the local profile cleared at log-off, could that be added to the description page?
This probably has nothing to do with 5.1. I believe the tool assumes that when the user logs off of the system, that the local profile is blown away. This is standard practice, both to reduce file crud creep on the OS and as a security precaution. Thus, the folder should not exist when the user returns to the system.
We have tried to use App-Remediation for some applications to roam the per user localappdata.
It works on a single machine copying files between the Appdata\local and Appdata\roaming\...\savedfromlocal locations
The problem we have is for a roaming user moving to a machine that has previously run the application. When it tries to copy from savedfromlocal to the Adddata\Local location we see a 'DOS box' for App-Remediation that does not complete the copy and times out after 30 seconds as specified in the xml script setting.
It seems to fail because the directory has a different timestamp to the target and the user does not have write permission so the Robocopy retries until the script timeout terminates the attempt?
is saved to:
When the user roams the directory:
has a different timestamp and the user does not have write permission so cannot overwrite it on the restore step
We are using App-V 5.1 (188.8.131.52)
The users have full rights to subdirectories such as
but read only rights to the toplevel GUID directory and the 'S' directory versions of these folders:
It seems App-Remediation may not work for App-V 5.1 or any version with these user read-only restrictions?