I got an email the other day from a guy who works for a large North American financial institution asking whether I knew of any customer who has successfully implemented Outlook in the cloud with VDI. I don’t, so I figured I’d post the story here and see if anyone with experience or a solution can post ideas in the comments?
What’s the problem?
The challenge stems from how Outlook connects to the Exchange Server and whether something called "Cached Exchange Mode" is used. If you’re not familiar with Cached Exchange Mode, it’s essentially a setting (literally a checkbox) in Outlook which configures Outlook to store a local cached copy of the user’s mailbox. This cached copy is stored in a .OST file, and the idea is that it makes Outlook performance fast since all the Outlook operations (selecting messages, navigating folders, searching, etc.) are done via the locally-cached .OST file rather than traversing the network.
If you don’t enable Cached Exchange Mode, (the opposite of it is called “Online Mode”), then the Outlook client must maintain a connection to the Exchange Server, and just about every single thing you do in Outlook has to be sent to the server. This is fine if you’re on the same network as the Exchange Server, but it makes Outlook unusably slow if you’re a remote user.
In fact if you Google for [outlook slow], just about every result suggests, “Enabled Cached Exchange Mode.” And in many of the forums, user comments are along the lines of, “I just ticked this box and it magically fixed everything."
So using Cached Exchange Mode when Outlook is not running on the same LAN as the Exchange Server is a de facto requirement of using Outlook.
Cached Exchange Mode in VDI and RDSH
If you deploy Outlook via persistent VDI images, you can use Cached Exchange Mode no problem since the .OST cache file will be part of the user’s persistent image. This potentially works fine, though some under-powered VDI environments might experience slowness as all of Outlook’s “processing” is done on the VDI host instead of the Exchange server.
If you deploy Outlook via RDSH (or Citrix XenApp, etc.), the specific guidance from Citrix, Microsoft, and others is that you should *not* use Cached Exchange Mode. Microsoft specifically says, "For the relatively few users who access Outlook through a remote desktop, this might be the ideal configuration. However, Online Mode against the Exchange server is still the most scalable and optimized configuration for large deployments.” Kraft Kennedy has a blog post explaining more about why you can’t use Cached Exchange Mode in shared non-persistent (including VDI) environments. (The comments are great too.)
The problem is that the .OST file is designed to be local, and since RDSH environments create a new session for each user, that user’s session won’t include their .OST file. So the options are:
- Copy the .OST file to the RDSH server as part of the login script.
- Remotely mount the .OST file across the network
Unfortunately the .OST files can be pretty huge since they’re the full size of the user’s mailbox, often times being tens of gigabytes), and copying them to a user’s session on logon isn’t practical. And since .OST files were designed to be local, they assume local-level disk I/O, meaning if you put them on a file share accessed via SMB then you spike the network and slow down Outlook, so that doesn’t work either.
This is why Microsoft and Citrix say not to use Cached Exchange Mode with RDSH. If you want to use Outlook on RDSH, they suggest that you put the Exchange Server on the same network switch as your RDSH server, and that’s what companies with internally-hosted Exchange have been doing for the last 20 years.
But now we move Exchange to the cloud...
Okay, so you’re an enterprise who’s been running your own Exchange servers for years and hosting Outlook via XenApp. No problem. But now you want to move towards a cloud-hosted Exchange provider. What do you do?
You can’t use Online Mode since performance would be horrible, and you can’t use Cached Exchange Mode since there’s no good way to deal with the .OST files in XenApp. Seriously… what do you do?
You could stop using XenApp / RDSH and instead move to full persistent VDI images for your users, but that’s a huge investment and a major rearchitecture just to get some mail working.
You could move your Outlook hosting to the cloud provider, but now that brings up a million other complexities. Do you move all your other apps to the cloud or do your users have multiple remote desktops? How do attachments and file storage work? What about authentication? What about the added cost of this? Can your provider even guarantee that your remote hosted Outlook is on the same LAN as your hosted Exchange? (Office364 can’t.)
You could buy a super fat network pipe between your on-premises Outlook hosting servers and your hosted Exchange provider, but how good would that really be? And how expensive is that?
You could use Outlook Web Access instead of the Outlook desktop app, but what about all the Outlook plugins that enterprises use?
You could not use RDSH/VDI and just give all your users laptops, but presumably you have some reason for RDSH/VDI since you’ve been doing it for the past several years.
You could not use hosted Exchange and bring it back in house.
Seriously, what’s the solution here? Any ideas?