Orphaned OST files with FSLogix Profile and Office containers.

Question

We have a fairly new deployment of Windows 10 Enterprise Multi-Sessions on Azure. We have been using FSLogix Profile and Office containers from day1. All is working fine with minimal issues but we recently performed some analysis of the container sizes and content and found something interesting.

For some users (around 10% say) their profile container seemed to be larger than the average and when we investigated the content and found an orphaned copy of an Outlook offline cache (OST, NST, OAB etc..) in the profile container in the default location (AppData\Local\Microsoft\Outlook).

All users effected have a working Office container with Outlook offline cache working without issue but for some reason have a orphaned version in their profile container also.

Going off the file creation dates of the orphaned cache it was created after the Outlook offline cache in the Office container but the "Modified" date of the orphaned cache files is before that of the one in the Office container. Its as if one day FSLogix turned off Outlook redirection and then later turned it on again.

Has anyone see this behavior before ?

This also brings a second question...
How do we delete the orphaned Outlook offline cache files from the profile container to reduce its size ?

If we write a script to run in the user context to delete this from the profile container then surely the FSLogix filter driver will intercept and delete the content from the Office container instead ??

I'm aware of the following but don't believe either is the cause of our issue..

If you delete the profile container (but not the office container) on next logon Outlook won't use the existing offline cache and will recreate a new one. There's not evidence to suggest the profile containers were ever deleted for any of these users as the folder/file dates of both containers are the same.

Switching from Outlook cached mode to online mode and back again may cause Outlook to create a new offline cache. Switching Outlook connection mode is disabled by GPO so not this either.

Our setup is..
Windows 10 Enterprise Multi-session 20H2
No additional profile management (just FSLogix)
Windows Defender Antivirus
Citrix VDA1912
Citrix WEM (but no profile management)

Answer 1

from: [https://learn.microsoft.com/en-us/fslogix/office-container-configuration-reference][1]

RemoveOrphanedOSTFilesOnLogoff
Type DWORD

Default Value 0

Data values and use

A value of '0' or lack of this setting results in no action. A value of '1' will cause duplicate OST files to be removed.

NOTE: Review the following, in full, before setting. In rare cases, duplicate OST files are created for a user. This circumstance has been documented to occur with and without the use of a non-persistent profile. When the profile is stored in the standard file system, administrators may remove orphaned or stale OST files by deleting them. When using Profile Container the OST file in a VHD, isn't as visible. Over long periods of time duplicate OST files may consume incremental disk space. Setting this option to 1 will cause Profile Container and Profile Container for Office to remove all OST files in a VHD(X), except the OST with the latest modify date. Administrators should be familiar with the use of OST files, and potential implications, before choosing to enable this setting.

Answer 2

We are experiencing the same issue, having the complete Outlook folder in both the Office and Profile containers, with the OST's this is using excess space than required.
Using RemoveOrphanedOSTFilesOnLogoff Type DWORD doesnt work.

Did you find a solution to this how to delete the OST from the Profile container?

Answer 3

We are having the same issue. We constantly have users that are running out of space in their Profile VHD and find that the OST files are duplicated. We have the RemoveOrphanedOSTFiles on logoff set but that is not working. We are looking for a way to programmatically delete them but no luck so far. The only way we can do it is to have the user logoff and mount their Profile drive and manually delete it.

Answer 4

Did you ever find a reason or answer for this?

We have the same issue.