Items from an Exchange Online System folder called "Files" are appearing in Outlook's Instant Search

[Chris Campbell]

Hello,

It was recommended that I post this issue here (originally posted here). 

We performed a migration from an on-prem Exchange 2010 server to O365 two weeks ago.  This was done via MigrationWiz though multiple phases over a weeks period (we're bandwidth limited), monitored and initiated by our tenant, Rackspace.

Since the migration has completed, we've had a few users reporting problems with their Outlook client search results.  Based on our initial research, and this previous Microsoft community forum thread, this appears it may be migration related (it definitely was not occurring with the on-prem exchange server.) 

When searching in Outlook 2016, these users are getting results from a hidden "files" folder that appears to be a special Outlook system folder.  These results screw up the results pane and can cause Outlook to be unstable and prone to crashing.

Summary of the problem:

When searching on Outlook 2016, search results return duplicate email that are:

Missing entries in the to/cc/from fields
Message title of "<This item contains active content. Open the item to read its contents.>"
All formatting in the email has been lost.  

In addition, it appears to only affect emails that contain attachments.  When hovering the mouse over the email entry in the search pane, the location tooltip shows "In Folder: Files".  The users impacted do not have a "Files" folder in their Inbox structure, and from our research, this appears to be a special/hidden Outlook folder.

Interestingly, we can not reproduce this when using Outlook OWA.  

During troubleshooting we have tried:

Quick/Full Repair of Office installations.
running scanpst.exe
rebuilding search index
stop&disable Windows Search Service.
creating a new mailbox profile
changing cached mode's time period
rebooting the system

None of these steps make any difference.  For one machine, changing the search target from "All Mailboxes" to "Current Mailbox" fixes the issue, but is a less than optimal workaround.  This workaround did not work on another system that I tested.

Can anyone provide a suggestion on what I can do to solve this issue?  This is extremely disruptive for these users (who rely heavily on search) and something we must solve.

Rackspace hasn't been much help and is advising creating a new user profile and/or running Microsoft's OffScrub tool.  We're hoping that this may be a somewhat common issue that is solvable and not something we just have to live with.

Thanks,
Chris

[#2]

The Files folder should not be exposed in clients, it's a system folder used to store copies of documents/attachments. You can read more about it in Tony's ramblings here: https://www.petri.com/mysterious-files-folder

One of the things you should do and I don't see listed above is to make sure you're using the latest Office build, as if I remember correctly some of the issues around the Files folder required client-side fixes. If you feel comfortable working with tools such as MFCMAPI, you can also explore one of the affected mailboxes with it and check the properties of the Files folder. As the Files folder only exists for O365 mailboxes, I dont exclude the possibility that the migration tool didn't know how to process it and/or made some changes in its properties. But that's just speculation on my side, best check with the vendor support, and also O365 support.

Another thing that comes to mind is to move the mailbox to a different DB and see if there are any changes, you can do this by running New-MoveRequest in the service.