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

Apply WS22 KB5035857 (12 March 2024 OS update), set KIR registry key below to activate fix and reboot:

HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides\721378957 = 1 (DWORD)

Answer 2

We're having a similar problem. The RDS servers reboot nightly.
Every morning, my first login Start menu search doesn't work, can't type.
After logging off and back on, it works, seemingly for the remainder of the day.
We're on FSLogix 2.9.7838. We were on a newer version with our 2019 server pool, but upon adding a 2022 server to the pool, login was completely broken or took upwards of 15 minutes, settings/appdata wasn't there, all kinds of broken.
I found a thread where someone fixed some issues rolling back to that version, so I tried it and it fixed my login issues.
I haven't figured out the start menu search problem yet.

Answer 3

We have the exact same issue on windows 11 avd multi user in azure. Windows 10 multi user isn’t having this issue. We are also using fslogix. What I see is when you restart the search service while the user is logged in around 6 or 7 files exist in the users search data applications folder in the path mentioned above. However on next logon when the search is broken again if you check that folder only 3 files exist. When you then restart the search service the files are recreated for the user and then the search is working again but only for the duration of the session.

Answer 4

Obtained a private fix from MS for windows 11 multi session avd which has fixed our search index issues in testing

Answer 5

Hi all, another update.

The support escalation engineer says they are indeed able to reproduce the issue (Windows Server 2022 RDSH only, FSLogix is innocent in this one :) ). So I had to fill out a "Business Impact" statement, which I sent this morning. That seems to be needed if the Product Group is to be involved for a fix.

For the time being, we are still using the "restart Windows Search" at user shell start event, but we had to reduce the Windows Search by using Group Policy (No cloud, no network drives, no file:///C:*, no file:///D:*, ...) to solve a growing performance issue related to Windows Search.

We noticed the more users got onto one system the more "explorer.exe" started consuming CPU cycles up to the servers being at 100% CPU by only explorer.exe processes. Stopping Windows Search service immediately lowered the CPU usage to normal levels, so we decided to stop some locations from being indexed. That did bring performance back to normal levels. At least Outlook's search index is still working, so most people do not see any difference (except OneNote search which is broken now :) ).

Anyway, still hoping for a fix, at least they are still "on the case"!