Cloud-hosted Exchange with RDSH/VDI Outlook is a performance nightmare. Are there any solutions?

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?

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?

Potential options

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?

Join the conversation

25 comments

Send me notifications when other members comment.

Please create a username to comment.

This seems to be a problem that could be "solved" by Exchange archive/retention policies (I have not tested it):


1. Use persistent profiles and cached mode.


2. Set default Exchange policy to move all messages older than two weeks or a month to online archive.


3. You could exclude from archiving messages that are flagged or unread


Messages that are older than a couple of weeks are rearly accessed (look at smartphone mail policies). Persistent ost will be tiny, but all current items will still be cached.


Cancel

Outlook 2013 has a configurable cache option that can help to manage the size of users' OST files. You could enable and configure that cache time length value by GPO, along with file location, to make profile management and/or scripting options more viable. Most users need their recent data frequently and don't mind short delays in finding older data as much, so even caching for a short time period would likely improve the user experience significantly.


Also, it's worth noting that Cached Exchange Mode is supported in RDSH sessions using Outlook 2013:


"Outlook 2013 supports running in Cached Exchange Mode in a Remote Desktop Services (Terminal Services) environment that has multiple users. When you configure a computer running RDS to use Cached Exchange Mode, be sure to consider the additional storage space and disk I/O that are required for multiple client access.


New Exchange accounts set up on computers running RDS use Online Mode by default. At setup, the user can decide to enable Cached Exchange Mode, or the user can control this setting by using the Use Cached Exchange Mode for new and existing Outlook profiles option in the Office Customization Tool or in Group Policy."


Reference: technet.microsoft.com/.../jj683103%28v=office.15%29.aspx


Cancel

Someone such as Citrix, Riverbed etc. must have support for caching of Exchange mailboxes to support Online Mode in Outlook, yet transparently cache locally via the network.


Cancel

How about using a GPO to redirect the OST file to a persistent location (user file share) ... that way it would get downloaded once and then reused... havent tried it, but in my mind it would work


Cancel

We are partially following what Shawn Jackson recommends in that we are configuring the cache option to control the size of the OST.  We are also a Unidesk customer so having that OST file reside in the user personalization layer provides the user a desktop experience but doesn't require we use all the resources of a typical persistent desktop.


Cancel

Using the OST cache slider in Outlook 2013 to retain only say 1 month worth of email offline for Citrix environment in order to keep the OST and profile size small.  Any emails that are over the OST 1-3 months will be retrieved on a query basis when you search which should work okay.  This means upgrading to Outlook 2013 though.


The main problem with slider in Outlook 2013 is additional mapped mailboxes.  When you assign permissions to a mailbox in Exchange 2010, the mailbox is automatically mapped to your Outlook profile.


If you set the main profile to 3 months, as an example, that will reduce you OST size, however additional mapped mailboxes are not affected by this slider setting.  So if you Outlook profile has an additional mailbox mapped in your Outlook profile which is say 1GB in size, the full additional 1GB will be downloaded locally, regardless of the slider setting.  There are ways around this they have there own drawbacks.


Roll on Outlook 201x.


Cancel

First I think the approach needs to be framed in the context of RDSH/XenDesktop vs RemoteApp/XenApp.  Big differences there.  Then, best approach will be determined by use cases. Important factors (some mentioned above) include:


-Users accessing shared or delegate mailboxes (-Automapping $False will be a consideration here when setting up mailbox permissions).


-Version of Office used in the environment:  Only Office 2013 supports the cached mode slider, and even then this doesn’t affect how much data is cached


-In my opinion, the CacheOtherUsersMail [false] option (set only in registry, if I remember correctly) is a must in all VDI use cases, this covers delegates and shared mailboxes.  Online mode should be the usage scenario for all but the user’s primary inbox and online archive.


My likely unpopular opinion on the matter as a whole:


Ultimately, I think that Outlook is best solved by the newest OWA version.  Shared/delegate mailboxes are accessible, as is the Online Archive.  The issue we run into here is other applications that leverage Outlook to function (as add-ins).  Notable examples include Microsoft Dynamics CRM, and System Center Service Manager.  OWA is a non-starter as soon as an application like this is added to the list of use cases.


Cancel

"Office364"


I like this :)


Nothing else to add that hasn't already been written above


Cancel

Some good ideas in the comments here. Excellent discussion. Maybe we should establish #FixOutlookOST. It worked for #FixVDA, remember?


Cancel

Important note on this.  Microsoft does not support OST files stored on the network, either directly, or via folder redirection.


I have just been having people beef up their internet pipe and work online.


Cancel

Whatever solution is implemented on a large scale it has the potential to essentially erase the savings in outsourcing email to MS. Or can possibly drive up your XA hosted or VDI costs to the point of not being practical and creating a complex solution with huge support implications.


Here are some options in order of what makes the most sense in my opinion


Deploy or keep an exchange environment onsite just for XA\XD users sized to be used with Online mode so that it provides a good user experience. Once the Fat client issue is solved you go web based O365 and shutdown the exchange environment.


Exit the XA Hosted strategy in the interim and continue to deploy laptops\desktops with local OST files and O365. Enable Remote PC via Citrix and allow the full desktop experience remotely with HDX with cheap local storage. Once the OST and fat client issue is resolved resume the program. Also in turn this will strategically enable the rest of your org to benefit from mobility and accessing their desktops and apps anywhere with very little spend.


Remove XA desktops and go non-persistent VDI desktop with OST on some persistent drive that is practically local. Sounds great but you are definitely going to need to look at layering technologies like someone mentioned unidesk, cloud volumes, fslogix and carefully pick your storage vendor. Also multi DC replication of the persistent drive could be an issue. Once the Outlook client issue is solved you go web based and reduce\remove the persistent drive.


Run in online mode with the Outlook client connecting to remote MS DC's against MS's recommended deployment method for O365. Hopefully their service is great and the pipeline in between is stable and every time someone sorts by name their mailbox doesn't freeze for 10 seconds. Caveat with this one is when their service does suck MS will not offer support because you do not have OST’s enabled


Data redirection on an expensive storage solution custom deployed to support OST file redirection for thousands of people just to make the O365 her experience better. Then you will be dealing with bloat, corruption and rebuild across the wan from MS, support nightmares and network traffic of thousands of users reading their OST’s across the lan.


Work with MS and see if there is an option to co-host your desktop workload along with your O365 service. Azure with Mail and Desktop service? If you are moving data into the cloud might as well put the desktop there as well?


On a large scale the problem presented is a complex one to solve good luck


Paul


Cancel

The solution is simple.


Microsoft must kill MAPI and move to pure HTTP in order to keep Exchange relevant in a cloud connected future.


Cancel

I also went through the "Online Mode" attempts with Outlook/Office 365 in VDI.   The performance was simply horrible.   Users with large calendars would find Outlook "not responding" as a result of the delayed connections to the "Cloud".


I ended up setting Cached Exchange Mode to 3 months by group policy to avoid a large OST with the advantage of being able to quickly search at least 3 months of email before looking for data on the server.   Search results or data past 3 months are represented by a hyperlink that says: Click here to view more on Microsoft Exchange..  Once the hyperlink is clicked, you the can view the data that's beyond your policy setting.  At this point we ended up getting an unexpected bug/feature as we were initially missing the hyperlink after setting the policy.   This was resolved by the following: support.microsoft.com/.../en-us.


If I recall correctly, MS reps said "online mode" wasn't officially supported for Outlook/Office 365.  At the time I found several conflicting documents so I don't know where they officially stand now, but I had no other option other than to go with what performed the best.


We are using XenDesktop 7.5 and I set all Office settings by local group policies using Unidesk 2.8 layers (Persistent Desktops).  By using layers I'm able to setup different users/VMs to different policies without having to mess up my automated AD OU placements.


Good luck!


Jon


Cancel

Hi,


I am writing this comment on XenApp 6.5. published desktop, where I run my Outlook 2010. I had 6GB big mailbox in total, thus I had a problem to search there, when my data were stored locally on our LAN mail server (not Exchange). I even try to store all my data on SSD tier, but it helped to shorten the search time cca in half only. Since our mail server vendor can were not able to offer any solution, I decided to test O365 Exchange, with cached OST. The result was the same: long search time - arround 30-60s. The problem is OST size/IOPS performance of HDDs. Then I set online access and voilá, the problem is solved. BTW I have believed, the online model is not  better option, but I was wrong. I search now just in a second, maybe 2 seconds at most. We have 70Mbit conection to internet and I can tell, that online setup is the quickest one. Please keep in mind, we have not a large deployment, but as soon as you have normal internet connction (from DC), it should be o.k.. Cached OST causes local IOPS problem (Exchange in O365 can provide much better results). I have not seen any freezing windows in Outlook at all, except for Internet connection failure.


I have not technical details how Outlook 365 search results are delivered to my Outlook, but the search itself is the same as for the Web access, and I have the same speed on my Outlook on published desktop as I have with Outlook WebAccess. Plus I have full Outlook mail client.


Well, I consider Office365 online to be perfect solution for me.


P.S: There is an option to run Outlook online with OST caching in background, please do not use that option, since it is useless


Pavol


Cancel

I wonder if this would be a good use case for HP's Moonshot product with each individual device having a dedicated local disk and resources. Either persistent image with the local OST redirection that would give a great user experience. Or look at a non persistent PVS Image with a persistent D: drive and the OST file redirected to the the local SSD dedicated to each device.


It would mean there would be a one to one ratio for users to device but the image management could be great with PVS non persistent depending on the app mix. User experience with a local OST and desktop in general as the resources are dedicated and the local storage is SSD. Also eliminating the hypervisor and license costs and management if you are a vmware shop, removes the guessing game of user experience with complex expensive storage and data redirection for the OST.


I doubt you would save any money overall with the moonshot product versus traditional VDI with XD\ESX and Storage but you may provide a less complex solution to support with an excellent user experience in a similar price range


Cancel

Hello all, great insight.


We have been working on this for our clients connecting to our Jentu low latency, high speed architecture for cloud and hybrid bare-metal cloud.


Brian wrote about us a couple of times in 2014,


www.brianmadden.com/.../remember-how-ardence-was-awesome-before-citrix-screwed-it-up-you-need-to-know-about-jentu-disk-streaming-to-physical-desktops.aspx


We have done it successfully, with a new client that is using it in their school campus.


Above someone said, 'Microsoft does not support OST files stored on the network, either directly, or via folder redirection.', but boy does it work with Jentu and near zero latency across all workstations.


I will be sharing our results and solution with Brian on our next call.


Cancel

I have successfully managed to get an application requiring “Cache Exchange Mode” using OST files and VMWare View VDI to work well.  I had users with 40-80GB OST files as they had 2 or 3 people they were responsible for assisting and each person had 10+GB mailboxes plus other mailboxes for terminated people and resources they had to manage. Granted the application that I had to use “CEM” mode for soon after updated and no longer required “CEM” so we dumped this method as we didn’t need it anymore. It requires the use of a second persistent disk and redirect all user profile information to the second persistent disk which then included all the application components and the OST files which we stored on slower 7200K SATA drives.  It worked and not really any slower than if we had just left the profiles on the local c: drive both of which we tested.  This allowed the linked clones to connect to the persistent profile storage that the application required along with OST file.  You could likely get away with just redirecting the OST with other applications but this one required so much more.  


Cancel

Oconn79, I see you had it running well, would you please share how, what was the implementation time per user, custom configurations etc.


I am trying to get an actual comparison.


Jentu, allowed the OST files to remain natural, only modifications are at the A/D level with simple GPO 'Group Policies'.


The simple difference, so far is with Jentu, the Desktop latency is sub >20ms as for outlook, even a Microsoft MCSD, stated, "Wow, I've never seen the solution to the problem before".


We had that captured on video for one of the Christmas parties as the company grows. Maybe will post one day?


Let me know if you want to see Jentu in action, find us on linkedin, Jentu Technologies Inc.


Cancel

I feel a hosted email solution that doesn't include a hosted email client is really only half a solution. Office365 was initially designed to host all email through OWA and all files through Sharepoint/OneDrive. To get the full Outlook client experience one would have to have an Azure based Outlook RemoteApp solution. Problem is how does one transfer attachments into and out of this environment. The answer is through the use of OneDrive for Business. I believe Microsoft now offers a package for this through Azure RemoteApps.


Cancel

Daniel Feller did a very relevant article on this:


How to use Outlook Cached Exchange Mode on XenApp and XenDesktop


virtualfeller.com/.../how-to-use-outlook-cached-exchange-mode-on-xenapp-and-xendesktop


also this:


Deployment Guide: Office 365 for XenApp and XenDesktop


www.citrixandmicrosoft.com/.../Deployment%20Guide%20-%20Office%20365%20for%20XenApp%20and%20XenDesktop.pdf


Cancel

I know this option been dismissed but since most people use folder redirection, why can't one redirect OST files? i know its questionable but not sure that Office 365 with Cloud exchange is officially supported on non-persistent environment anyways ...is there a technical reason that you could find to explain why its not supported?


Cancel

I'm having horrible performance issues with O365 Online|Outlook 2013|RDC and am looking for ways to continue troubleshooting.


Backstory:  I work for a County Attorney Association that does application support for a Case Management software that assists the County Attorney's in paperless case management and electronic court filing. We in the midst of doing a version upgrade for the 3rd party case management application the counties I support use. We run a "shared" server with multiple VM's for the smaller counties with limited budgets for IT support.  A few of those counties have migrated to 365 on the cloud, but connect to those email accounts via Outlook 2013 on the "shared" server. They connect via RDC to a hosted Windows Server 2012 R2".  There is an Add-In installed by the 3rd party vendor for both Outlook and Word. It allows them to enter email and documents into the case management software.  Performance is sub-par but they insist it's not the 3rd party case management software. The Add-Ins appear to function correctly, however we have multiple crashes when trying to update the calendar, as well as degradation in creating/generating documents/emails.  What I'm looking for, based on your responses to this OP is a way to fix this that isn't cost-prohibitive.   We are talking about county government, which everyone knows has little to no money for a complete rearchitecture of the system. (Side note: This is a brand new server that was built ~30 days ago and we performed a migration to the new server at the same time as a version upgrade of the case management software released.)  We have several counties that use O365 but have local servers and have zero impact in performance. I'm trying to narrow it down to a few key pieces, but it seems the 365|Outlook 2013|RDC piece seems to keep rearing it's ugly head. I've even tried Caching Mode, and after reading this will be reverting those changes.  Any ideas would be most helpful. Both the counties and myself are getting frustrated (especially because I don't admin their 365 accounts)


Cancel

@stucco It is not true that Microsoft do not support PST/OST on network shares, I also use to believe this was the case. There are circumstances where they are supported. See the text below from this article .. support.microsoft.com/.../297019


Outlook 2010 or later versions functionality is supported when networked .pst or .ost files are used under the following conditions:


•A high bandwidth/low latency network connection is used.


•There is single client access per file (one Outlook client per .pst or .ost).


•Either Windows Server 2008 R2 or later Remote Desktop Session Host (RDSH), or Windows Server 2008 R2 or later Virtual Desktop Infrastructure (VDI) is used to run Outlook remotely.


If a specific Outlook feature stops working or the .pst or .ost file becomes corrupt and you can reproduce the issue in the above environment, contact Microsoft Support.


Cancel

We're having this issue also. I run VMware Horizon View with linked clones and as our VM system drive size is only around 40GB I don't want this to run out using OST files.


I have done a bit of research and whilst I understand MS are looking to move as much as possible to the cloud, I believe we can get away with using a hybrid Exchange environment - so I'm going to look at building a local mailbox server and keep Outlook on the clients in online mode, and use the Office 365 component for transport and so on. This way we also have control over archiving, litigation hold and other configuration.


Has anyone else looked at this method? I'd be interested in suggestions.


Cancel

Great disucssion and a hot topic for our environment now, given the business transformation needs of almost every global organisation. Thanks alistg I will give that guide a crack and see if a difference can be made to improve the user experience.


#pvs #nonpersistent #O365


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close