<img alt="" src="https://secure.inventive52intuitive.com/789747.png" style="display:none;">
Office 365 performance issues in virtual environments

Office 365 performance issues in virtual environments

Posted by HTG

Ain’t that a mouthful of a title for a post? 🙂

Having spent part of last week at BriForum London, it’s interesting to come away with a broader view of what is happening in the virtualization world.

One of the things I found most intriguing was the perception that on a number of levels, desktop virtualization – either on full-fat VDI or hosted shared desktops – is moving into a much more mature phase. Issues with storage and infrastructure are much less noticeable, and Moore’s Law has seen that we now have solutions that are much more capable of dealing with the nuances of a virtualized desktop environment. Hyperconvergence, superfast storage arrays, GPUs – technologies that can deliver have overcome a lot of the early blockers to widespread virtualization adoption.

But of course, there are still problems to be overcome – the final pieces of the jigsaw to be put into place, the last bumps in the user experience to be ironed out.

One of these is the performance of Office 365 in the virtual environment – particularly in the Citrix-provided desktop arena. Assuming you’re using the “Exchange Online” version of Microsoft Office (rather than the full-fat web-based version), where there is still a client involved, you may well have come across some of these performance problems.

Microsoft generally recommends using Cached Exchange Mode for Office 365, in order to provide acceptable startup, session, and search/indexing performance. But in XenApp environments, the user OST cannot be stored locally as the user may not always land on the same server for their next session. In non-persistent XenDesktop environments, the user profile is discarded between sessions, and again, the OST file cannot be stored locally.

You also can’t use traditional UEM solutions to deal with the OST file as imagine a user with a 15-20GB mailbox – do you want to copy that down onto the endpoint at every logon and back to the network at logoff? Redirection doesn’t cut it, because that’s an unsupported configuration. If you bite the bullet and use Online Mode, you’re going to give yourself a lot of availability and performance issues (large calendars being a particular bottleneck), as well as a substantial increase in network overhead.

So while using Cached Exchange Mode is the main performance tweak Microsoft recommend for Outlook, they also don’t recommend using it for Remote Desktop Session Host. If you’re doing RDSH, then they suggest that you keep the Exchange server on the same network switch as the RDSH server. But we’re using Office 365 – and we’re not in a position to put our RDSH into Azure as well – so what do you do?

Microsoft do offer some mitigation, after a fashion – for instance, GPOs exist that allow you to limit the cache option to just a couple of months’ worth of email, but this simply “hides” the issue until the user starts searching for mail from more than a specified time ago. Creative systems administrators can also attack this issue in a huge number of ways, limited only by their imagination and technical skills/budgets. They could go fully persistent VDI, purchase themselves a whacking great pipe with incredible amounts of bandwidth, use custom retention policies, get Microsoft to kill off MAPI – the possibilities are endless. But each of them have pros and cons, support implications, and possible architectural changes to plan and implement. And in the end (and I think this is the most worrying point) – the overhead of dealing with the performance issues can potentially essentially erase the cost savings in outsourcing email to Microsoft in the first place. Or can possibly drive up your XenApp hosted or VDI costs to the point of not being practical. Not situations anyone wants to be in!

There’s got to be a simpler answer, hasn’t there?

Well, step forward FSLogix.

FSLogix have a track record in providing “point” solutions to particular pain areas that users and administrators experience in the here-and-now. None of the “let’s re-engineer your entire infrastructure” approach that you get when talking to some software vendors – what you get is straight-to-the-crux-of-the–matter solutions for the problems that are burning you today.Image management issues? Flip the whole golden image model on its head and just reveal applications to the user as necessary with FSLogix Apps.

Java version hell? Just block the out-of-date versions from the operating system and only reveal them when required with the FSLogix Java Rule Editor.

And now, if you’re suffering from poor hosted Outlook performance on XenApp/XenDesktop/VDI/RDSH, then along comes FSLogix Office 365 Containers.

Office 365 Containers use the same engine as all of the other FSLogix features, simply using a filter driver to seamlessly mount a centrally-managed container for the OST file into what is effectively local storage. What’s more, it simply slots into your existing deployment infrastructure, managed easily through ADMX files that integrate seamlessly with Group Policy objects.

Over at my affiliate company HTG, we’ve been testing with the release version of Office 365 Containers and we’ve observed a 45% improvement in initial Outlook startup time, a 52% improvement in search performance, and a 75% decrease in the size of the local user profile, all by using the lightweight FSLogix agent. This was done across XenApp 7.8 on Server 2016 VDA, and XenDesktop 7.8 on Windows 10 VDA. A snapshot of our testing results for these platforms are below (broken down to an average):-

XenDesktop 7.8 on Windows 10 VDA

Outlook “logon” time

In standard configuration – 7m 34s

With FSLogix Office 365 Container – 0m 34s

Outlook search time (for obscure item)

In standard configuration – 0m 38s

With FSLogix Office 365 Container – 0m 6s

User profile size

In standard configuration – 426MB

With FSLogix Office 365 Container – 102MB

XenApp 7.8 hosted desktop on Server 2016 VDA

Outlook “logon” time

In standard configuration – 8m 12s

With FSLogix Office 365 Container – 0m 58s

Outlook search time

In standard configuration – 0m 49s

With FSLogix Office 365 Container – 0m 8s

User profile size

In standard configuration – 408MB

With FSLogix Office 365 Container – 92MB

On top of this, there is a noticeable decrease in network utilization and latency observed when using the FSLogix solution. I’m still compiling all the results from the lab (network stuff not being my favourite area!), but it seemed to be in the region of a 25% reduction, which again, in a Citrix environment, is not to be sniffed at. I don’t expect you to just take these lab results at face value, though – every enterprise is different – so I’d recommend you get a demo set up and test yourself.

And this isn’t limited to just getting cached Exchange mode working with Outlook – you can also use this to work with the OneDrive cache and the cached information in Skype for Business too.

Of course, now that I’ve said that, you want to know how easy is to set up and demonstrate this saving in your environment? Well, it’s only a six-step setup routine, so it doesn’t get much simpler than this, in my opinion…

  • Launch your XenDesktop or XenApp endpoints
  • Install the FSLogix Apps agent onto the endpoints using your preferred mechanism (manual, SCCM, script, the choice is yours) – no reboot required
  • Set up a file share to host the containers for each user
  • Load the provided ADMX file into your Group Policy Management Console
  • Specify the GPO settings required and assign them (in a simple configuration, only two of the available settings are needed to get up and running)
  • Log on with your test user, and test the performance increases for yourself

This is me laying it all out simply – for instance, in a Provisioning Server environment, this process would be somewhat less straightforward, but I’m sure you all get the gist of how it is intended to be set up 🙂

But anyway, the key takeaways are clear from this…

  • 25-30% network resource savings on XenApp or XenDesktop
  • Approximately 83% decrease in Outlook startup time
  • Approximately 80% increase in search and indexing performance
  • Around 75% decrease in local user profile size (although you’re offloading it somewhere, to be fair)
  • Simple, easy setup that integrates seamlessly into Active Directory environments

What’s not to like? Another piece of the jigsaw is in place!

This may sound like me pushing out a big fat advert for FSLogix, but it’s far from that. I like to see software that fixes particular pain points that people talk to me about on a regular basis, and that’s exactly what this is. I’ve seen many an Office 365 implementation fall apart or get abandoned because of precisely the issues that this product is trying to address. Anything that brings us closer to the perfect user experience, in my humble opinion, is something that’s well worth looking into.

Prior to this kind of solution, I always had big misgivings about putting Office 365 onto, in particular, a Citrix platform. It feels like that blocker has now been cleared firmly out of the way, and that’s a very welcome development.

If you want more info on FSLogix Office 365 Containers or to even get a demo lined up, then get in touch.

And finally, thanks to all who attended my BriForum sessions and gave me feedback – I had a great time and hopefully everyone learned something useful!

Contact

Want to partner with us?

Get in touch to learn more about our services or arrange a free 30-minute consultation with one of our Secure Cloud Experts.

Get in touch
HTG - Contact CTA