Occasionally Persona Management fails to populate the local copy of appdata/roaming with data from the persona repository. When this happens, the appdata/local portion (we are using persona on both local and roaming) of the persona is always downloaded successfully. We have a ticket open (14459879303) but the next step in VMwares support advice was to disable DFS (they didnt specify the namespace or roaming, just quoted MS's articles that warn about multiple targets could get our of sync profiles http://blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.as…). We are only using DFS for its namespace and to replicate a copy of the repository over to another server for backup purposes. The second server is never an active target so we dont believe that DFSR is the issue and would like to query the community for other ideas and advice, maybe to even have one of you try reproducing our findings of having a long DFS Namespace
I have read that if persona encounters long file names or encrypted files that it will halt. VMware did not state that they found this to be our problem from review of our logs but I wonder if they can even tell, the WMWVvp.txt is hard to read. This leaves us wondering how we can further troubleshoot the issue ourselves. The last thing we want to do is stop using DFSN or DFSR.
When someone logs in and they dont get their appdata/roaming, if they start up an app that was once customized with settings in appdata/roaming, their settings are lost and when they log off, the new settings that they make during that session are written up to the server. This is bad for a number of apps. In the meantime we have resorted to preloading appdata/roaming whcih causes a long login and delay.
Could it be our provider order? No, we adjusted it to have SEP last and that did not help.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order|Provider Order|SnacNp,RDPNP,LanmanWorkstation,webclient,wsnotify
http://www.symantec.com/connect/forums/snacnp-network-provider-order-best-order
Here is an error from WMWVvp.txt during a login that failed to download the appdata/roaming directory that is not in the log on a successfull login:
[RTOLogon!VMWCreateOfflineFilesFromDirBuffer] Failed Creating Local Folder:
Persona logging continues and at some point, at least the appdata/local directory gets created and some preloaded data gets downloaded from the repository.
We modified the persona path to several different values and tested. The values below indicate if the path was a DFS Namespace or a UNC path, how many characters the path consists of, and the percentage of times persona failed to download or set up the link between the repository and appdata/roaming
DFS (30) \\DOM.local\shares\vdiprofiles 25%
DFS (24) \\DOM\shares\vdiprofiles 0%
DFS (47) \\DOM.local\shares\virtualdesktopinfrastructure 100% (yes, thats a 100% failure rate)
UNC (26) \\DOM-ABC-FS1\vdiprofiles$ 0%
If it matters, these tests were run on a user with a username that consisted of 11 alpha characters, so the roaming folder is at \\DOM.local\shares\vdiprofiles\usernameabc.DOM.V2\AppData\Roaming . Keep in mind that the appdata/local folders that were specified to preload worked in all the above tests and if we specify to preload appdata/roaming, there is never a failure (this results in extremely slow logins) its just the appdata/roaming that runs into trouble. This suggests that the appdata/roaming profile magic that persona is trying to perform is failing for some reason when the name of the DFS path exceeds some length. We did not test an extremely long UNC path.
Clarified some, added content