In the Environment Manager 2018.3 release we added support to our Cache Roaming feature for concurrent user connections to Office 365 from multiple sessions or desktops. This article discusses the pros and cons of our model compared to other approaches. The goal is to ensure that when a user has multiple non-persistent desktops or sessions connected to Office 365, Environment Manager can successfully maintain a local cache of data for each Office 365 app without conflict.

Environment Manager Data Sheet

Alternate Approaches

Some vendors chose to use differencing disks by default.  With this approach a difference –puh –yas disk is created for every concurrent logon and resides within the same network location as the Parent (Master) VHD file. Every VHD file created will contain a merge of the cache from the parent VHD file which, in theory is great but in practice does not play out well when using Outlook Cached Exchange mode, as the .OST file is hashed and deemed outdated by Outlook when attempting to retrieve the profile cache.

At logoff each client attempts to merge their VHD with the base disk and this merge will only succeed if this is the last VHD(Session) to do so. If other sessions are still active the merge will fail and the disk along with the user’s cache will be deleted.

This gives the effect of 'last write wins' (or more exactly 'last logged out wins') which in theory is practical but in practice does not satisfy key office 365 use cases for Non-Persistent environments such as Cached Exchange mode. This model can result in an unpredictable cache lottery where multiple sessions attempt to write to and merge with the base disk with no way of tracking the result and predicting the cache they will retrieve at next logon.

The Ivanti Solution

With Environment Manager Cache Roaming a VHD is attached to the user’s session at every logon. The VHD is mounted and the cache from the configured Office 365 applications is redirected to it from their native locations within the user profile. The cache is then subsequently read from the VHD at block level ensuring Office 365 has the rapid access required to provide a seamless and native user experience.

When the user logs off, the VHD is detached and the VHD file is unlocked ready for the next session. If a user does not logoff and a second concurrent session is created, they will be presented with a new, blank secondary VHD file. At this point NO merge between the VHD’s will be attempted and the user’s office 365 data will be streamed down and redirected locally to the new VHD.

At Logoff from concurrent sessions, a maximum of 5 VHD files are retained, per user. This ensures the user will have a healthy pool of VHD’s to call upon when multiple sessions are active, with data being retained and promptly restored on demand.

VHD Concurrency in Environment Manager 2018.3 – a working example:

  1. User Joe.Bloggs logs on to a Citrix XenApp server. A VHD file is created and attached to his session labelled Joe.Bloggs.VHD.

  2. The user launches and configures Microsoft Outlook and OneDrive. The caches for these applications sync with Office 365 and files are redirected into the VHD. Joe logs off the session and the VHD file is detached and unlocked and stored on the network ready for the next session.

  3. The next day Joe.Bloggs logs on and the Joe.Bloggs.VHD file from yesterday is attached to his session and the cache is ready for the launch of Office 365 applications.

  4. This time instead of logging off, Joe.Bloggs disconnects from the session leaving the VHD attached and the Joe.Bloggs.VHD file on the file share locked.

  5. Later, Joe.Bloggs logs on to a Citrix XenDesktop VDI and so now has two concurrent sessions. In this scenario the original VHD file (Joe.Bloggs.VHD) cannot be attached as it is still locked in the disconnected XenApp session. A new VHD file (Joe.Bloggs1.VHD) is created and attached to the second session.

  6. When Joe.Bloggs opens Outlook and OneDrive in the second session Office 365 will sync the user’s cache from the cloud whilst redirecting it locally into the new Joe.Bloggs1.VHD.

  7. All Office 365 cache generated within this second concurrent session is synced with the user’s Office 365 cloud storage whilst also being redirected to the Joe.Bloggs1.VHD file. When Joe.Bloggs logs off this second session the VHD is detached, but not deleted and is retained on the network.

  8. When Joe.Bloggs logs off the original XenApp session the base disk Joe.Bloggs.VHD is detached, but not deleted, and will be available on the network alongside Joe.Bloggs1.VHD as the primary choice for any new sessions spawned by the user.

  9. At this point Joe.Bloggs has now been logged out of all sessions in all environments. At next logon the original Joe.Bloggs.VHD file is attached if it is unlocked. Should it not be available the next in line is Joe.Bloggs1.VHD and so forth. The maximum number of VHD’s per user is 5 ensuring a significant but manageable number of disks are readily available to attach and restore the Office 365 cache with all changes in sync.

Please refer to our Cache Roaming compatibility matrix below for information on supported concurrency configurations:environment manager office 365 cache roaming concurrency screenshot

* Please note with ‘Windows & Outlook Search’ Cache roaming template the system wide search index is roamed capturing both Windows & Outlook search cache. This is ONLY supported on single user workstations with no support for concurrent sessions.

Take windows 10 to the next level