Providing fast mailbox access to Exchange Online in virtualised desktop scenarios

In last week’s post that provided a logical view on end user computing (EUC) architecture, I mentioned two sets of challenges that I commonly see with customers:

  1. “We invested heavily in thin client technologies and now we’re finding them to be over-engineered and expensive with multiple layers of technology to manage and control.”
  2. “We have a managed Windows desktop running <insert legacy version of Windows and Office here> but the business wants more flexibility than we can provide.”

What I didn’t say, is that I’m seeing a lot of Microsoft customers who have a combination of these and who are refreshing parts of their EUC provisioning without looking at the whole picture – for example, moving email from Exchange to Exchange Online but not adopting other Office 365 workloads and not updating their Office client applications (most notably Outlook).

In the last month, I’ve seen at least three organisations who have:

  • An investment in non-persistent virtualised desktops (using technology products from Citrix and others).
  • A stated objective to move email to Exchange Online.
  • Office Enterprise E3 or higher subscriptions (i.e. the licences for Office 365 ProPlus – for subscription-based evergreen Office clients) but no immediate intention to update Office from current levels (typically Office 2010).

These organisations are, in my opinion, making life unnecessarily difficult for themselves.

The technical challenges with such as solution come down to some basic facts:

  • If you move your email to the cloud, it’s further away in network terms. You will introduce latency.
  • Microsoft and Citrix both recommend caching Exchange mailbox data in Outlook.
  • Office 365 is designed to work with recent (2013 and 2016) versions of Office products. Previous versions may work, but with reduced functionality. For example, Outlook 2013 and later have the ability to control the amount of data cached locally – Outlook 2010 does not.

Citrix’s advice (in the Citrix Deployment Guide for Microsoft Office 365 for Citrix XenApp and XenDesktop 7.x) is using Outlook Cached Exchange Mode; however, they also state “For XenApp or non-persistent VDI models the Cached Exchange Mode .OST file is best located on an SMB file share within the XenApp local network”. My experience suggests that, where Citrix customers do not use Outlook Cached Exchange Mode, they will have a poor user experience connecting to mailboxes.

Often, a migration to Office 365  (e.g. to make use of cloud services for email, collaboration, etc.) is best combined with Office application updates. Whilst Outlook 2013 and later versions can control the amount of data that is cached, in a virtualised environment, this represents a user experience trade-off between reducing login times and reducing the impact of slow network access to the mailbox.

Put simply: you can’t have fast mailbox access to Exchange Online without caching on virtualised desktops, unless you want to add another layer of software complexity.

So, where does that leave customers who are unable or unwilling to follow Microsoft’s and Citrix’s advice? Effectively, there are two alternative approaches that may be considered:

  • The use of Outlook on the Web to access mailboxes using a browser. The latest versions of Outlook on the Web (formerly known as Outlook Web Access) are extremely well-featured and many users find that they are able to use the browser client to meet their requirements.
  • Third party solutions, such as those from FSLogix can be used to create “profile containers” for user data, such as cached mailbox data.

Using faster (SSD) disks for XenApp servers and improving the speed of the network connection (including the Internet connection) may also help but these are likely to be expensive options.

Alternatively, take a look at the bigger picture – go back to basics and look at how best to provide business users with a more flexible approach to end user computing.

2 thoughts on “Providing fast mailbox access to Exchange Online in virtualised desktop scenarios


  1. Hi Mark, disclosure here – I work for an FSLogix distributor. I believe that FSLogix is the simplest and most elegant way to solve this challenge. While an OST file on the network might be a workaround, I don’t think it’s supported by Microsoft and it’s easy to corrupt OST files in the event of network issues.

    I totally agree with you on a flexible approach to EUC, but many organisations have significant investment in an SBC/VDI solution and this helps to protect those investments, while providing users with an experience closer to a physical desktop. Happy users is key to ensuring remote desktops solutions are successful.


  2. Hi Aaron, great to hear from you – and thanks for sharing this post in your network! I’m pretty sure you’re correct that OSTs on network shares are unsupported by Microsoft – kind of catch 22 – follow Citrix’s advice or Microsoft’s! That’s where FSLogix comes in and, although I have no direct experience in it, I do have customers and potential customers who are looking at it seriously.

    My personal view, however, is that VDI was always sticking plaster, and should not be viewed as strategic. Many organisations have made significant investments and now find themselves bound by multiple layers of technology. From a strategic viewpoint, SBC/VDI is best viewed as a necessary evil to respond to technical debt – there are better and more flexible ways to deliver applications to users in 2017.

Leave a Reply