Managing Office 365 performance issues

Office 365 has been upon us for a while and represents one of Microsoft’s big pushes (alongside Azure) towards their “cloud first, mobile first” model. Most of us haven’t gone for full-fat Office 365 just yet, because of a few Office 365 performance issues with the web-based versions such as missing functionality, and a reliance on internet connectivity.

Most of the 365 installations I work with are still using the Office client software – it’s just their email infrastructure which has been offloaded to the cloud.

It’s probably more accurate to refer to this model as “Exchange Online” rather than “Office 365”. If you suffer an outage, you can still work on documents stored locally – you simply lose the email connection, as if your on-premises Exchange server had gone down. It also says a lot about how much people clearly didn’t like managing Exchange servers, as the “Exchange Online” model has grown quite quickly!

What are the trade-offs and Office 365 performance issues?

But this “Online” model comes with trade-offs. Especially if you’re using any form of hot-desking solution, or a shared session model like Remote Desktop Session Host or Citrix XenApp, or non-persistent VDI of any flavor.

On Exchange Online (yes, I’m going to use the term, hope it catches on!), Microsoft has always recommended using Cached Exchange Mode (CEM). But they’ve also never recommended that for RDSH or non-persistent VDI or roaming setups, because CEM involves keeping a local copy of the mailbox (the OST file) to give acceptable logon, startup and search performance. You’re either going to have to roam the OST file around (imagine copying down a 15-20GB file, in some cases, at every logon), or recreate it every time the user starts Outlook. Both of these options have a major performance hit.

Microsoft’s actual advice for RDSH Outlook instances is to keep the Exchange server on the same network switch as the RDSH server. But if you’re on Exchange Online, and unwilling to put your RDSH instances into Azure as well as the email, then that’s a non-starter. What can be done?

There are some options in this area, to be fair:

• You could enable GPOs to limit the cache to a few months’ worth of mail – but that’s just hiding the problem until the user looks for older mails.
• You could change to fully persistent VDI.
• You could purchase a huge amount of bandwidth to ensure a superfast connection to your online Exchange server.
• You could use custom retention policies.
• Hell, you could even try to get Microsoft to kill off MAPI, if you were so inclined.

What these options have in common is that they all involve big changes, support implications, and potential costs and resource to implement. What it can also do is create a big overhead that potentially erases the cost savings you saw in going to the Exchange Online model in the first place – and this is a major PITA, to be honest.

Isn’t there a simpler answer?

Well, there is.

Several companies – Microsoft, LiquidWare Labs, and FSLogix – have solutions that can redirect the entire user profile to a centrally-managed VHD or VHDX file. Microsoft has User Profile Disks, LiquidWare have ProfileDisk, and FSLogix has Profile Containers. Microsoft’s UPD is somewhat limited (it is bound to a single Session Collection), and LiquidWare and FSLogix offer this functionality as part of a full user profile management solution. So although these technologies can address the issue, there are drawbacks. For the MS offering, it’s not very flexible, and for the other two, they involve investing in a profile management solution that a) you may not want, or b) you may already have one purchased and deployed.

The FSLogix solution, though, has now been altered to overcome this.

Rather than purchasing the full Profile Containers product, a cut-down version of it is available called Office 365 Containers. This works on the same principle (redirecting to a VHD or VHDX file), but operates only for the Outlook files. It is also, as you’d expect, considerably reduced in price because of the cut-down functionality.

It’s also remarkably easy to deploy. You simply install the agent (no reboot required), configure a Group Policy Object to select the settings (such as size and location of the mounted file), populate a local group with the users you want to apply it to, and it is ready to go.

Testing shows you can get a 40-80% saving in logon time, Outlook startup and Outlook performance (tested through mailbox search) using this technique of network-mounted files for the OST. It is also considerably more efficient than using a redirected folder, because it is only one file that needs to be read from and written to, rather than tens or hundreds of files like you would see on a redirected folder. This also means a decrease in network utilization and latency. You also don’t see any OST corruption, you get the performance of CEM without any of the drawbacks, and it is all invisible to the user (unless they can spot a junction point).

And the best bit is, this can be extended to any user function that suffers in VDI, RDSH or roaming environments. I’m thinking things like the OneDrive cache (or other EFSS solution), Skype for Business GAL, and Windows Search. Especially on RDSH or XenApp (and particularly in environments like Citrix Provisioning Server), Windows Search has always tended to be disabled, resulting in loss of functionality for the user. Using this technique, it doesn’t have to be this way.

As I said, the functionality is available from UPD, ProfileDisk, and FSLogix, but FSLogix is the only one currently offering a cut-down way to achieve this specific functionality without buying into a wider suite or limiting the deployment capability. In my opinion, it’s almost a no-brainer to add this functionality – functionality a lot of people have wanted in their Exchange Online deployments for the last few years.