The other day, I was in my workshop building a new desk for my wife when one of my kids came in asking me about the different tools I had scattered all over the room. I said “this is a radial arm saw, this is a circular saw, this is a band saw and this is a scroll saw”. Of course they asked “Why do you have so many saws?”. I replied “Because each saw does something really well and if I use the wrong one for the job, we will have big problems.”
Your IT toolkit will also contain many different tools, but it is important to understand when to use which tool.
In my last blog, I talked about how using a network share to store your Cached Exchange Mode files (.OST) for Outlook IS supported on a VDI and RDS solution like XenApp and XenDesktop. The basis for the blog was because I kept hearing and reading conflicting answers.
After the blog, I got a bunch of tweets, emails and comments disagreeing with me. They didn’t disagree that it was or was not supported on a XenApp or XenDesktop implementation, they disagreed because it is a bad idea to use the feature in an RDS and VDI implementation. Citrix even has an article that basically says do not turn on cached exchange mode. If you do, your email might be slow, your VDI/RDS will be hit at the CPU level, and network usage will increase. The Citrix recommendation is to use online mode where all of the processing happens on Exchange server and you keep an open connection between Outlook and Exchange.
Historically, this is how I’ve seen most implementations and it would be safe to assume that this would be considered a best practice. And I 100% agree. The previous blog simply states that storing the Cached Exchange Mode file (.OST) on a network share is a supported option, but with most decisions there is an appropriate place.
There is a reason why this decision has become more important to me.
I’ve recently been spending more time working with Office 365. My question now is what do I do if I use Exchange Online? Easy, use Outlook online.
Unfortunately, that doesn’t always work as users are accustomed to their local install or you have apps that rely on the local install of Outlook client. So in the scenario with Exchange online and Outlook installed locally, would you still use online Exchange mode? Have you actually tried it?
I have. It isn’t the most pleasant experience. To do online mode effectively, you really need a low-latency network link. Neil Johnson at Microsoft posted a blog a few years ago looking into the connection status for Outlook. Based on the blog, an optimal experience is to have your max average response time be less than 325ms. My IT delivered Exchange was 4ms, which makes perfect sense considering Outlook client and Exchange are on the same, low-latency network. Online Exchange mode works great for this scenario. But my connection to Exchange Online from Office 365 was 110ms. Not bad right? Unfortunately there were noticeable performance issues that shown themselves as application lags (you would click an email and it would take a few seconds for the message to appear).
This is making our traditional best practice of using online mode for XenApp and XenDesktop implementations not so strong. In reality, you are probably going to do something like
- If Outlook client (running on XenApp or XenDesktop) and Exchange server are on the same low-latency network, use online mode
- If Outlook client (running on XenApp or XenDesktop) and Exchange server are not on the same low-latency network, use cached exchange mode with network storage.
But that isn’t the end of the story. We will want to optimize Outlook for this implementation.
Stay tuned for more…
Cached Exchange Mode Blog Series:
From the virtual mind of Virtual Feller