FSLogix and Windows Search Issues in Server 2022

Question

Hi All,

There are quite a few archived forums regarding this issue, however I am hoping someone can help. I am using FSLogix with Windows Server 2022 Remote Desktop Services. The environment is simple, with two session host servers and a file server hosting the user profile VHDs. I am not using FSLogix cloudcache, therefore profiles are mounted and dismounted over the network at logon/logoff. It's working great, except for issues with the Search Index!

Some common threads here which I have reviewed in detail.
https://social.msdn.microsoft.com/Forums/en-US/a9b5000d-e2a8-442b-9cbf-48e05136f732/support-for-server-2019-and-office-2019-search-roaming?forum=FSLogix
https://social.technet.microsoft.com/forums/en-US/e87a25c5-71b8-412a-ba82-b7fa07a7363b/windows-search-changes-in-server-2019-rds?forum=winserverTS
https://jkindon.com/windows-search-in-server-2019-and-multi-session-windows-10/

As per https://learn.microsoft.com/en-us/fslogix/configure-search-roaming-ht I am aware that FSLogix no longer requires a specific configuration in place for search roaming as per user search is now native to server 2019/2022, therefore I have configured the following. I actually read that the latest version ignores these settings anyway, so if they are enabled via registry or GPO they are simply ignored.

FSLogix > Enable search roaming > Disabled
FSLogix/Office 365 Containers > Store search database in Office 365 container > Disabled
FSLogix/Profile Containers > Store search database in profile container > Disabled

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search\EnablePerUserCatalog=(dword)1 - I can prob remove this as 1 just means per user, which is default. I just set to 1 as I have previously tested by setting to 0 which sets the index to machine wide. Still had the same issues.

Anyway I know its working per user as I can see the EDB file created in AppData for each user:
C:\Users\%username%\AppData\Roaming\Microsoft\Search\Data\Applications\S-SID...

From all accounts, the index is working and is built for the user, however ONLY if the Windows Search service (set to auto) is restarted while the user is logged in. As the user logs out, I can see in the event log.

event ID 1 / Search-ProfileNotify is thrown: Windows Search Service indexed data for user 'domain\user' successfully removed in response to user profile deletion.
I suspect this may be a normal event due to the profile being dismounted and removed from the RDSH server.

Following that the Search Service needs to be restarted before seeing event id 326:
The database engine attached a database (2, C:\Users\username\AppData\Roaming\Microsoft\Search\Data\Applications\S-sid.edb). (Time=0 seconds)

I realise some of the other forums suggest just using a scheduled task to restart the search service every time this ID is thrown... which I can do... but the issue is even if the user logs back in, event ID 326 is not seen for that user until the service is restarted again. I can confirm the index is not all that healthy as from outlook if you select Search Tools > Indexing Status, its just stuck on Loading... forever until you restart the service and then it gives the correct status, will continue to index and write to the .edb files above etc.

So restarting the windows search service only seems to apply to users that are already logged in. I realise I could run a scheduled task to restart the service at logon too, but I thought better to reach out to the community to see if anyone actually has a resolution for this!! Microsoft, if you're listening, it would be such a great thing to fix for us all!!

Hope to hear from someone having a similar experience.

Cheers.

Answer 1

Anyone had an update for this? We are holding off going live with a client on 2022 until this it resolved. Dont fancy 350 users not having properly indexed mailboxes.

Answer 2

It's a shame the search was never fixed. This problem is years old

Answer 3

Hi all, Here with an update again. The fix provided did not work. I contacted MS and the support escalation engineer tested it in his lab and verified that it doesn't work. This is his latest update:

Hey again, Currently ( since I have the repro) it’s a back and forth with logs from my machine to the PG as the private did not fix it here either.So collecting TTDs and sending it to them. I tested two additional private fixes so far.

I got this info 25/01/2024, so they are still actively working on it!

Answer 4

Hi Bart,

Kudos to you for providing insightful updates on the issue with Windows Servers 2022 index. I've encountered identical issues with the Windows Index and attempted various solutions before stumbling upon your Q&A thread in this forum.

I'm curious to know, what triggers the restart of the Windows Search service in your scenario? Additionally, aside from the elevated CPU usage in Windows Explorer, are there any other drawbacks associated with this workaround?

Answer 5

Hi all, An update! Microsoft provided a working private fix. I installed it and tested on my clean test lab and it works. This fix requires test signing to be on, so for the moment I have not tested it on our much more complex Citrix PVS golden image yet. I will try to do this soon, but I am already excited that they did get a working fix. Apparently the first fix was ok, but the packaging of the fix had gone wrong.

If you can read dutch (your name somehow makes me think you do), read my Server 2022 blog here https://www.nimble.be/gastblog-door-bart-een-reis-door-de-upgrade-van-microsoft-windows-server-met-citrix-pvs/ In English: I created a scheduled task that restarts the Windows Search service at this event: event id 2 from “Microsoft-Windows-User Profile Service/Operational” Profile Service. However, it will get you corrupted search databases ... .