Using FSLogix Office 365 Container for Outlook Search in Non-Persistent RDS Environments

Posted by Benny Tritsch on Sep 6, 2017 1:41:40 PM

Find me on:

When Outlook is running in cached Exchange mode, Outlook data is stored in user-specific .OST files. These .OST files must follow the users as they roam from host to host. Windows Search Service indexes locally stored .OST files and creates an index catalog for each user to enable search functionality in Outlook. In non-persistent and load-balanced Remote Desktop Service environments, the index catalog doesn’t roam with user data. As a consequence, the index catalog must be rebuilt every time the user logs in and the Connection Broker send him or her to a new pooled desktop or a different RD Session Host within a Collection. FSLogix’s Office 365 Container was designed to solve this issue by roaming a user’s Outlook data as well as their search index catalog in such a way that it is compatible to the Windows Search Service. The FSLogix O365 Container implementation is based on a file system filter driver that redirects the users’ .OST files to virtual disks attached to the local file system in such a way that makes the VHDs look like local folders. This enables users to use the local Windows Search service in Outlook while they are accessing their emails. But how good is this solution in terms of performance and end user experience? The folks from RDS Gurus have the answer.

RDS Gurus has written about FSLogix before, for example here. Now RDS Gurus has cranked up their benchmarking lab and conducted a thorough REX Analytics test which illustrates the user experience of remote desktop users while they are searching their Outlook mailboxes in an RDS environment. Two different settings were configured, one using FSLogix Office 365 Container and another using native RDS User Profile Disk (UPD) technology. The goal was to measure how performance degrades for the primary user in focus when multiple secondary users are simultaneously searching Outlook (“noisy neighbor effect”). Here is a summary of the results:

  1. User experience is similar if Outlook is indexed. While there are some differences in the resource consumption between UPD and FSLogix technologies (this is more evident through performance counter logs and graphing), the user experience for users using UPD and using FSLogix is very similar if the user’s Outlook is indexed.
  2. User experience with FSLogix wins when users roam. When users roam from RD session host to another RD Session host, their search experience is far better with FSLogix. This is because it roams the search index on per user basis inside the user’s profile container; there is no need to re-index a user’s Outlook OST no matter which RD Session Host server they end up on. During our test runs we could observe time and time again that secondary FSLogix users that had Outlook indexed had a far better user experience in than secondary UPD users who had to have their OSTs indexed. The FSLogix secondary users got consistent returned results for searches that used the Windows Local Search service while the UPD secondary users did not.
  3. Windows Search Service is fragile – FSLogix helps. Relying on Windows Search service in a multi-user environment is fragile. During several test runs, we had to quit the run and redo it because certain buttons (local search oriented buttons) were greyed out on the Outlook Search ribbon. Restarting the Windows Search service fixed this issue, but what the specific problem was with the Windows Search service remains a mystery. And because the issue happened more than once it does not instill great confidence in the Windows Search service. The users will get little or no results returned for Outlook searches that use the Local Windows Search service (searches for All Outlook Items and Searches in Subfolders) while the index is being rebuilt. With FSLogix, this is not the case – the effects of one user’s search index does not affect the other users, as each user has their own search database file.

It is important to note that the Windows Search Service is not officially supported on multi-user installations. So it being fragile is true, but it’s at least partly due to using it in an unsupported manner. But using Office 365 Outlook in RDS environments without integration into the local Windows Search Service is unacceptable for many corporate users.

For details check out the RDS Gurus article “Outlook Performance in Non-Persistent Environments Using FSLogix’s Office 365 Containers“. Microsoft references the RDS Gurus findings in the blog article “Dealing with Outlook Search in Non-Persistent Environments“.

This article was originally posted at http://drtritsch.com/2017/08/25/using-fslogix-office-365-container-for-outlook-search-in-non-persistent-rds-environments/

Topics: RDS, Office 365, Outlook Search, Windows Search Service

Subscribe to Email Updates

Posts by Topic

see all

Follow Me