ErikTatum10's Accepted Solutions

Hi, You used the words "profile folder" in your question, but are asking about a change to the product that is for redirected folders only.  If you want admins to have access to the profile fo... See more...
Hi, You used the words "profile folder" in your question, but are asking about a change to the product that is for redirected folders only.  If you want admins to have access to the profile folder, please use the Microsoft GPO setting that does this.  Otherwise, you would need to update to 5.3 or later to get this feature for folder redirection.  The admin template just provides the configuration interface that enables the product code that implements the change.  If you choose to update to a newer version of Persona, I would suggest you bypass 5.3 and go to 6.0 or later to pick up more bug fixes and a more stable build. Thanks, Erik
Hi Cameron, For the purposes of this explanation, power outage, reset, and crash are the same. I'm not sure whether you have floating or persistent desktops, but that's important because it... See more...
Hi Cameron, For the purposes of this explanation, power outage, reset, and crash are the same. I'm not sure whether you have floating or persistent desktops, but that's important because it affects the way this all works.  Floating desktops create interesting challenges in power outage scenarios with respect to data loss.  On persistent desktops  the local profile is on the desktop and if the machine crashes the data can be recovered on the next logon (assuming the data was successfully written to disk before the power went out).  This is not the case with floating desktops unless the user is lucky enough to get reassigned to the same desktop on the next logon, which is not likely. That said, here's some details of how the replication engine works.  Every ten minutes (default) or whatever you have configured, the changes made during that interval are uploaded to a hidden temporary directory in the root of the roaming profile.  This folder name is a guid that starts with {d2...}.  Once that step is complete, the data is merged into the roaming profile itself.  If something like a crash or a reset happens before or during the upload to the temp directory, the upload is considered invalid and thrown out.  Anything else would result in a corrupt profile (i.e. a partial upload would result in a profile that is not in a crash-consistent state).  So, if a user changes a file and the machine goes down before all of the data from the delta is uploaded, the changes would be lost on a floating desktop scenario.  The replication engine is designed to ensure a crash-consistent state in the roaming profile in all cases where it's possible for us to ensure that. So, if the VM of a logged on user gets reset or crashes, it's very likely the user can lose data for the reasons I explained above. If the host goes down, I think this is a similar scenario as the VM crashing.  If the datastore hosting the desktop goes down, I think this is again a crash scenario.  If the connection to the central profile store is lost during the user's session, Persona will cache the changes locally and replicate them once the connection is restored.  Again, things get complicated if the user logs off while the CPS is disconnected on a floating desktop or if refresh on logoff is enabled. You are correct, "{08C31585-259A-4341-9982-78E42EAF6106}\computername.0.lck" is created by Persona and it is how we ensure only a single session is replicating to the roaming profile.  I'm sorry the support person told you this is not created by Persona.  They were definitely wrong.  Unfortunately, if the desktop loses power while Persona is holding this lock, sometimes the file server will not receive the signal to release the lock.  This not really a Persona bug as much as it is a catch-22 within the file system.  Imagine you and I were on the phone and I pulled the plug on my end, but you kept hearing my voice.  You wouldn't know to hang up because I kept talking and didn't say goodbye.  Basically, the file server isn't hearing "goodbye" and doesn't release the lock.  The file server should release the lock when the Persona service process stops (even if Persona didn't close it explicitly), but that doesn't happen cleanly in a this kind of situation, so it doesn't get the "goodbye" message.  I am not sure if this a persistent bug in Windows, NTFS, etc of it's a design issue that Microsoft cannot work-around. The profile will not work correctly again until the lock is cleaned up.  At this time, the only way I currently know to clean up the orphaned file locks is to reboot the file server. So, yes, we can expect data loss to happen if the desktop is reset unexpectedly and the data hasn't been replicated yet in some cases.  Sounds like this may be what you are experiencing.  Profile corruption is a term often misused.  In your case, I think you are seeing data loss due to the outages, not profile corruption.  I would expect your roaming profile to be in a crash consistent state, but missing the last set of changes the user made.  Is that what you are seeing? I hope this helps to answer your questions.  If not, please feel free to ask more. Thanks, Erik
Hi Eric, Persona does not currently support the use of wildcards in any of the configuration options.  So, "AppData\Roaming\test_*.doc" and "AppData\Roaming\Mozilla\Firefox\Profiles\*\minidump... See more...
Hi Eric, Persona does not currently support the use of wildcards in any of the configuration options.  So, "AppData\Roaming\test_*.doc" and "AppData\Roaming\Mozilla\Firefox\Profiles\*\minidumps" will not work.  However, I tested "AppData\Roaming\Macromedia\Flash Player\#SharedObjects" myself with 5.2 and it works fine.  Please note that "Files and folders excluded from roaming" will not remove any existing files from the remote folder.  It simply prevents the files in the remote folder from being created in the local folder during logon and it prevents any changes in the local folder from replicating to the remote folder.  This allows you to disable the setting and go back to the original data if you need to. Please let me know if you have any further questions. Thanks, Erik