Today I found myself, again, working with a customer that complained of poor performance in Outlook in combination with Office 365 (Exchange Online) on an environment using RDS. The main complaint is Outlook is slow when switching between folders, opening shared mailbox or using different calendars.
The reason for these issues is simple: when moving from Exchange on-prem to the cloud, the network latency between the clients and the Exchange-server increases and every glitch in the network becomes noticeable. When using ‘fat clients’, you can make sure Outlook is running in ‘cached mode’, so you work from your local .ost-file that syncs with the Exchange servers, thus eliminating most network issues. In RDS (or VDI, for that matter) setups, this isn’t always an option. So how to fix these issues?
First of all, you need to make sure you environment is set up in the best possible way. This TechNet blog can help you optimize and troubleshoot your Office 365 network connectivity. Especially the DNS-settings mentioned in the blogpost can be a culprit. Make sure you use DNS servers in the same geographical location as you RDS/VDI servers, so you get redirected to the right Exhange Online servers in the Azure network. More good pointers on optimizing network performance can be found here.
If all this is okay, you can use cached mode on your RDS/VDI environment. Default, the .ost file generated when using cached mode will be placed in the appdata\local directory, which causes it to not be included in roaming profiles or folder redirection. This way, when you log on to your RDS farm and are being redirected to a new server, your local cache will need to be rebuild. You can avoid this by redirecting the .ost file to a network share using a group policy. Please be aware, that previously this wasn’t a supported environment. However, with modern Outlook clients (specifically Outlook 2010 and above) this is supported. You can find detailed information here, but to summarize: if you use a high-speed, low latency network connection between your Outlook client and the file server, are using Server 2008 R2 or higher for your RDS/VDI and make sure there is ‘single file access’ to the ost-files (in other words: only one process (or user session) will access the ost-file at the same time), you are good to go.
Be aware that redirecting the .ost file does have some impact on search functionality in Outlook. The search is based on indexing by the Windows Search Service, which runs on the client computer. This means that when you are redirected to a different server, search may not be (completely) available within Outlook due the ost-file being re-indexed. Also, you need to plan you deployment and make sure you have enough disk space and disk I/O to serve the OST-files.
As you can see, these performance issues probably need to be fixed within the Outlook client. Until that happens, using cached mode can be a alternative to improve performance, although it does have some side-effects.
Of course, investing in an ExpressRoute connection, and realizing a low-latency connection to Office 365, could also solve (at least some of) these issues. However, if you would like to use ExpressRoute to connect to Office 365 you would need the premium plan which isn’t cheep.
For me, running cached mode in RDS/VDI with a limit of 6 months to cache offline seems to work OK, but you’ll have to learn how to live with the drawbacks.