One of the biggest problems in a SBC (Microsoft Terminal Services or Citrix XenApp) and VDI (Citrix XenDesktop and VMware View) environment is that of the issues caused by the dreaded Roaming Profile. One such issue which plagues both users and IT Support desks alike is Profile Corruption.
Profile corruption is seen as innevitabele when using roaming profiles, and can leave a user locked out of their desktop for hours, support desks inundated and overwhelmed with support cases, and is a huge drain on resources at great cost to a business.
AppSense Environment Manager not only prevents Profile Corruption, but also enables IT Support desks to reduce other profile related support cases from being a 2 hour resolution process, to just 5 or 10 minutes. This not only improves user satisfaction, but makes for a more efficient, and lower cost support desk.
Profile corruption can occur through the overwriting of user settings as a user logs off from concurrent working sessions and settings made in each separate desktop try and write back to a central store. Often overwriting each other, causing conflict, and leading to corruption
With AppSense Environment Manager, when a user launches an application, regardless of how it is delivered to a user (local install, Citrix, Microsoft App-V, VMware ThinApp, InstallFree etc…), we inject a Profile Virtualization Component (PVC) into the running process which allows any personalized settings, i.e. writes to the registry or file system, to be virtualized and therefore effectively redirected to a ‘local virtualization cache’ located on the user’s endpoint or within the user session itself (in the case of TS/XenApp). This is an automated process, no need for manually specifying which registry keys or settings to capture.
When the application is closed (not just at user logoff), the contents of the ‘local virtualization cache’ (only those [delta] changes made by the user during this running instance of the application) are then synchronized to a back-end database server so that a centralized copy of the user’s personalization settings is now available and able to be streamed back into open concurrent sessions or across multiple delivery mechanisms.
This eliminates the last write wins at the session level by not writing back to NTUSER.DAT at logoff. Significantly reducing the window for corruption as settings are syncronized back throughout the user session, not all in their entirity at logoff.
So now as an additional benefit, settings can be shared across concurrent sessions as the next time the user launches the same application, be it from the same or a different concurrent session, the contents of the ‘local virtual cache’ are checked to see if the settings are up-to-date. If they are, the user will get their latest personalization settings from the local cache. If the settings are out-of-date, then the new delta user personalization settings for that specific application will be streamed down to the endpoint device on-demand.
With remediation tools such as Profile Rollback, application settings (which are stored in the SQL database at a per application level for each user) can be rolled back with just a couple of clicks in the AppSense console. This takes 2 hour support calls down to just 5 or 10 minutes, and the beauty is, as the user settings are virtualized and so are not part of the desktop itself, the user need not log off their session for the rollback to occur. Merely close and re-open the application in question..
AppSense 