QuickPost – adding shared mailboxes in Online (non-cached) mode

Very quick “quickpost” today – this is more of a note to self than anything else, but some may find it helpful.

If (like I do currently), you have users that use many large shared mailboxes as well as their own mail accounts, you may find sizing for container solutions (such as those provided by Microsoft and Citrix, among others) a bit challenging. Obviously, this all boils down to the use of Cached Exchange Mode for good performance in VDI and/or RDSH environments.

Background

There are two ways to connect Outlook to an Exchange account: Online Mode and Cached Exchange Mode. While Online Mode maintains a direct connection to an Exchange server, Cached Exchange Mode creates a local copy of the mailbox data stored on the Exchange server in an offline data file (.ost file). Outlook accesses this cached copy for most operations speeding response times. Outlook and the Exchange Server synchronize the local and server data periodically.

Cached Exchange Mode is the issue – as many of us move inexorably towards Office365 with Outlook hosted in the cloud, we need to use Cached Exchange Mode. Using Online Mode only gives acceptable performance when there is a low-latency connection between the Outlook client and the Exchange server. With on-premises hosted Exchange, this is fine – the Citrix session hosts and the Exchange servers are located on a low-latency, high-bandwidth network. However, the connection between the Citrix session hosts and Office365 Exchange servers in the Microsoft cloud is subject to much more latency. If we use Online Mode, all of the processing and searching is then done at the Office365 end – and the latency means the performance of the application is slow, giving users a bad experience.

Cached Exchange Mode uses a file called an OST file – essentially a cache of the user’s mailbox that sits local to the Citrix session host. This means that there is a “local” copy of the mailbox items that can be accessed by the user and that henceforth doesn’t suffer from latency issues. However, the obvious problem with this is that Office365 allows up to 100GB of mailbox capacity, and caching up to 100GB of data into an OST file can be a nightmare in terms of storage and network bandwidth. There is also the issue that users can hit many servers within a Citrix or RDSH farm, so unless there is a way of saving the OST file and roaming it with them, you need to recache at every logon. And even if you did have a way of roaming the OST file, would you then have to copy that 100GB of data at logon and logoff to the profile location?

Traditionally, Citrix recommended using OST files that were stored on the network, to avoid having to recache an OST and also to avoid the copying of the OST data to persist it between sessions. Whilst this worked to a degree, it was also an unsupported configuration from Microsoft. Microsoft’s statement runs as such:-

Customers are responsible for both defining and maintaining adequate network and disk I/O. Microsoft will not assist in troubleshooting slow performance due to networked .pst or .ost files. Microsoft will only assist if the performance issue is reproduced while the .pst or .ost file is located on either a hard disk that is physically attached to the computer that is running Outlook, or on a virtual hard disk (VHD) that is attached to the virtual machine that is running Outlook

The key differentiator here, though, is the mention of a virtual hard disk. Vendors such as Citrix, Microsoft, Ivanti and Liquidware now provide the capability to map the OST file – or indeed, the entire user profile – to a VHD file. Essentially, the virtual hard disk is mounted as local storage, but physically exists on a network share. The block-level access means it is addressed as a single file, rather than many – improving performance for the user – but also crucially, meaning that a network-stored OST can be provided without placing the solution into an unsupported configuration. Citrix’s implementation of this technology is done through a User Profile Management (UPM) feature, whereas Microsoft obtained the functionality by purchasing a startup called FSLogix, and adding their products to Windows license entitlements.

To maintain good performance, we need to implement a container-based solution for the OST files, so that a) the configuration is fully supported, b) users do not need to copy their OST files at logon and logoff, which would impact KPIs, and c) the in-session performance of the Outlook client remains acceptable. The image below shows the performance uptick observed from using Cached Exchange Mode.

This brings us to the question of storage. For each user, in the default configuration, the cached OST file would cover one years’ worth of mail, which can be a large amount. This is clearly not an optimal configuration, as the initial year of email cache can be quite large. Fortunately, there are options to mitigate this.

GPOs can be configured to limit the cache size in terms of specified days, months or years. This will only cache mails from the specified time period, whereas all other mails reside on the server backend. This has the dual effect of increasing performance (as users interact primarily with recent emails rather than older ones), but avoiding the need for large amounts of cache storage. You can create groups which would apply a cache size of anywhere from three days to the entire mailbox, but generally enterprises opt for tiers such as 1, 3, 6 and 12 months. If any testing indicated users with particular issues related to older mails, you can increase their “caching tier” by changing their group membership.

The Group Policy Objects that drive the cache size are set under User Configuration | Administrative Templates | Microsoft Outlook 201x | Account Settings | Exchange | Cached Exchange Mode. The settings that need to be configured are “Use Cached Exchange Mode for new and existing Outlook profiles” (set to Enabled), and “Cached Exchange Mode Sync Settings” (set to different levels for different user groups, and normally applied via a Security Filter).

A user with a 30GB mailbox, for example, only has an 800MB cache when set to three months. This is not an absolute example – the size will differ dependent on volume of mail, attachments, folder layout and many other factors – but is merely entered here to give an indicative figure.

Shared mailboxes

Doing the sizing is very important when it comes to planning storage – and if all of your users just use a single mailbox account, and you have an idea of the average size of OST files, you are in a good place for estimating the storage requirement. If, though, you have users who are commonly using large shared mailboxes as well as their primary account, this can muddy the waters considerably.

Consider ten users with access to an 80GB shared mailbox. Are you going to have to factor in additional OST files for a cache of the shared mailbox for all of these users, generating even more storage overhead? If you add additional mailboxes, you may well see additional OST files being created in LOCALAPPDATA\Microsoft\Outlook as it begins to cache them into the user profile. Additionally, how does this affect synchronization of the items in the shared mailbox when users are caching some content out locally – could conflicts arise between the users connected to it?

In order to avoid this it’s prudent to allow the primary mailbox to run in Cached Exchange Mode and all the other shared mailboxes to run in Online mode. Whilst the performance will be impacted within the shared mailboxes, it’s assumed that these shared mailboxes won’t be the ones in which the users are spending most of their time. If they are, then you may need to rethink your approach somewhat to maintain an acceptable level of performance.

Enabling shared mailboxes to run in Online mode

Fortunately, turning this on is pretty straightforward. Firstly, you need to set a couple of additional GPO settings.

The first is User Configuration | Policies | Admin Templates | Microsoft Outlook 2016 | Account Settings | Exchange | Cached Exchange Mode and the setting is Download shared non-mail folders. This needs to be set to Disabled as below.

The second is User Configuration | Policies | Admin Templates | Microsoft Outlook 2016 | Outlook Options | Delegates and is called Disable shared mail folder caching. This needs to be set to Enabled as below

Finally, you need to make sure that your users are adding their shared mailboxes not as full, separate Exchange accounts, but as additional mailboxes attached to their primary (thanks to Michiel over on World of EUC for pointing this out to me). If you’ve got autodiscover correctly configured then the additional mailboxes that they have delegate access to may well be automatically added in this fashion, but just in case it’s not working seamlessly, this is how they should be added so that they don’t operate in Cached Exchange Mode.

Go to File | Account settings | Account settings, click on the primary mailbox, click Change, click More Settings, click Advanced, and click Add to add an additional mailbox

Enter the name of the mailbox, then click OK, Next, Done, Close and then restart Outlook.

Assuming your policies are applying correctly, you should then see that your primary mailbox is running in Cached Exchange Mode so that you get best performance…

…but the additional ones are set up in Online mode and are therefore not impacting local storage…

…and your users are only creating a single OST file for the primary mailbox.

So that’s that – a quick reminder for myself as to how to make sure you don’t have to provision tons more storage than you require when sizing for containers with shared mailboxes.

I will imminently have part #5 of my Logon Times series available – I am in the process of crunching all the data and pulling out the conclusions, so stay tuned!