When organizations deploy non-persistent VDI or Published Desktop type solutions it unfortunately is very typical to have your users to struggle with performance issues when using the full Outlook client. It can be extremely frustrating to a user that when something perceived to be as simple as accessing email is just miserably slow. That being said, let’s look at this issue in more depth to get a better understanding of the underlying issues and potential workarounds to this issue.
So what is the Underlying Cause of these Latencies?
The answer to this question lies primarily within the need to use Outlook cache .ost files, and how they function. Outlook can be configured to leverage locally stored offline cache files referred to as .ost files to overcome performance issues in a physical hardware workstation deployment. In this case, offline cache files will live on the local hard drive of the system which conforms to the Microsoft support policy for these files. When accessing them in a virtualized environment these files will now live in the user profile stored on the network. To add to the complexity, offline cache .ost files are designed with expansion capabilities to ensure that all mail becomes cached in the file, and the growth of these files can become unpredictable. It is the inefficiency of how this file type functions over a network that creates the Outlook Performance challenges we face in our VDI deployments.
How can I Resolve these Performance Issues?
Well, this is not really one-size-fits all answer, and will largely vary depending on your environment design. Let’s take a look at some of the options we can consider:
Email through a Web Application
Leveraging “Outlook Web App (OWA)” or the newer product version called “Outlook on the Web” can be a viable option. This is also regardless of the whether or not your email deployment is on-premises or in the cloud. From a performance perspective this application was designed to work remotely from anywhere, so in general this option will work very well. More specifically this option is very suitable for organizational users that do not sit at a desk all day. A great example would be in the healthcare space with physicians and nurses. Their roles offer a lot of mobility and their primary work device will be a tablet or phone making them great candidates for email through a web application. There are some organizational roles that would become inefficient through the use of an email based web application. For example, the sales representative that relies heavily or their Outlook plugin that integrates with their sales application will not be a good candidate for web based email.
Lastly some organizations have not embraced the use of web-based email in general. So there could be a cultural resistance to moving away from a full Outlook client. If organizational culture doesn’t embrace this option then it may take time to validate whether or not this can be adopted on any level.
Outlook Anywhere
Outlook Anywhere is an efficient option for accessing Outlook through a full email client in a secure and remote fashion. It can also be referred to as RPC over HTTPS. When setup correctly it can be used from within your organization or outside of your organization without cache mode, while still achieving reasonable Outlook performance. If your organization is moving to Exchange 2016, the implementation equivalent would be MAPI over HTTPS just using a slightly different protocol. Your functional Exchange design and underlying network bandwidth consumption will impact the level of performance benefit seen by this configuration option. However, this performance hinges more heavily on a rock solid Exchange design, and proper Outlook configuration. The following post discusses what the Outlook configuration should look like for this scenario.
Storage and Network
I recently had a conversation with someone that asked me if VDI performance on-premises deployed on all flash storage would eliminate any Outlook performance issues. The answer is that while there would be some improvement there is still network latency factor due to how the .ost file functions that is not being eliminated through the storage refresh. The .ost files in VDI live on a network share and need to be accessed over the network within a traditional VDI deployment design. So, improving the storage would not completely resolve the issue.
That being said engaging your network team or doing some of your own network packet capture traces to collect more detail can still prove useful. If there are any network improvements that can be made, these traces would provide that insight.
3rd Party Products
I am a firm believer in that if something can be done natively without introducing third party products then it should be, but there is also a break point where the effort it takes to leverage native products efficiently can become counterproductive. When leveraging Outlook with Cached Mode enabled within your VDI deployment, it is worthwhile to research and trial 3rd party products options to determine if this will meet the needs of your business users. Third party products have found ways around storing the .ost file on the network, and instead providing access to it in a way that the virtual machine perceives it as local to the virtual machine. Through your research and product trials you will quickly learn if this is a suitable option for your deployment.
Concluding Thoughts
Overcoming Outlook performance issues is a common VDI challenge that we a learning to overcome within how we design our environment. This design isn’t limited to your VDI architecture, but revolves more strongly around email architecture, Outlook configuration, network bandwidth and 3rd party products. With the right solution in place your users will be extremely happy with their virtualization experience.
Sponsored by
