This message was deleted.

i need to update the search article this week - wanna send me details of what you are doing and ill reference it?

sure, I can write something up

Latest server 2019 with latest fslogix - I couldn't get the search service to fail - any patterns I can test to try and reproduce the problems?? Mine was just basic windows and no outlook work to start with

Outlook and an office container along with a profile container seem to be enough. I just changed jobs and they are seeing it too, I’ll get some screenshots

I wanted to confirm the Search Service on 2019. I assume, its like 2016. No Roles, Just make sure the Search Service is stopped for the O365 Binaries to get injected into window search?

It’s per user search on 2019, different to 2016

Ok, That is what I was wondering.

The issue is you can’t roam the search database in the outlook container anymore because it’s not controlled by fslogix. It lives in appdata so gets picked up by the profile container.

Are you having issues with 2019 and Fslogix with Roam to 0? Just curious, I thought I read that on you experince

Even with roamsearch off you still get issues because the search service keeps a lock on the per user database in the vhd so it doesn’t unmount

Which is why the schedule task is needed

If you kill the service and start it up again it let’s go of the lock and it’s fine, even with others users on the box as it starts as needed

So this only affected office container? I am trying to understand where the issue is being broke at

I don’t have access to that environment to double check what caused what, but we were seeing the office container get corrupted with roamsearch enabled

I made a mistake I said search needed to be stopped. Referring 2K16. The king said. But Microsoft Office must be installed whilst the Search Service is running, else the search components for outlook will be missing