We have been using view since 4.5 was released and are currently on 5.2.0 build-987719. We have 8 pools using 8 parents (all windows 7 32bit) with 2 floating pools and 6 dedicated pools with about 130 active sessions during the day and 200 powered on machines. I have persona management turned on for every pool saving the PM profile for all pools on a dedicated drive on our file server. We have 5 hosts in the cluster with DRS and HA turned on. 90% of my users are from 1 floating pool, 5% are in the 2 dedicated pool and the other 4% are random users in the other floating pool and 1% are single users in test pools.
For the past 3 months or so we have had users call into the helpdesk reporting that they can't print or get to "my computer" that explorer.exe crashes on them. In all the troubleshooting we've done I've narrowed it down to this:
I do have a ticket open with VMware and have provided them with agent logs from a machine/user having the issue and agent logs from a machine/user not having the issue. This ticket has been open since November 25th however and no progress has been made.
As another note we just noticed and have started tracking, but users that logged into view the previous day have not reported the issue. For example if we get a call on a Friday, that user was never signed in on Thursday. Which means that users that are in the system daily only call us with issues on Monday while users that don't use View daily might call us any day of the week.
In case others having this issue find this post; I think we have found the issue. The Persona Management storage location was on a Win2012 Server with Data Dedupe turned on. Once we turned that off and forced a rehydration of the data profiles stopped getting corrupt. Please note that turning Dedupe off just stops new data from deduping, so you have to rehydrate the data. Additionally, we did have some users that would log in and had a corrupt profile, but then researched showed the last time they had logged in was before we turned off the dedupe so we suspect that their profile was already corrupt. It's been 3 weeks since we turned dedupe off and the issue has not reappeared since.
I know It is an old Post just wanted to add if it could help someone
This issue occurs when the Persona Management GPO is configured to preload huge files during logon. Dpending on the size of files and the load on the storage and network, a preload task may take approximately 5-10 minutes.
This issue occurs if, during the preloading phase, a user gets impatient and reboots the machine and reconnects to the session, sometimes multiple times in a row, expecting a faster access to their desktop.
In this case, a second session on the same allocated desktop gets created. However, the Persona Management agent cannot be used in two different sessions at the same time stops synching.
The second instance notices the folders being blank, and synchronizes this back to the share, deleting the whole profile.
Starting with Horizon View 5.3.2 and 6.0, the Horizon View agent includes a new session locking mechanism, which refrains access to the desktop if a Persona Management sync operation is already in progress for this user account.
To increase the user experience when the files and folders are too big in size, it is recommended to use Folder Redirection.
Note: Ensure to take a backup of the profiles to prevent data loss.
While I'm sure this is valid, I can say that in our environment we are only preloading desktop icons and we have not had a single issue since turning off deduplication on the Windows Server.