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

Hi all,

Another new development: I got this mail yesterday:

"We just got info from the Product Group – they did the backport and created a test package with the fix."

I'm currently unable to download the test package, but that should hopefully be solved today.

Looking forward to testing it and moving to a definite fix!

Answer 2

I've been doing some testing. The issue (for as far as I know) has nothing to do with FSLogix. I was getting ready to create a ticket with Microsoft for this issue on Server 2022 and I was documenting the steps, testing the search functionality after every step. I Installed Windows Server 2022 Standard (Desktop Experience) and did all Windows Updates => Search is ok (Indexing options are available, search is system wide). Next step: add Remote Desktop Session Host role => Search is broken (Indexing options stay on "waiting" until search service is restarted). Process explorer shows the "searchindexer.exe" process does not create a handle to the users search database.

I have a call to demonstrate the issue to Microsoft in 45 minutes, so hopefully they will be able to do something about it. I can't really believe they are not aware of this ... .

I've been using a "restart windows search" scheduled task on event id 2 from Microsoft-Windows-User Profile Service/Operational “Profile Service, which does the trick, but I doubt this is what we want ... .

Answer 3

An update:

I've had several calls with Microsoft now, including one on 1/09/2023 with the engineer who actually found both the Server 2019 and Windows 11 Multi User issue. He clarified a lot, and did indeed see a problem, so we collected more procmon traces and logs. If they are sure there is an issue, they will start simulating themselves.

Something I think I read in another thread surfaced after the call. If I reboot the server, the first user has a working search, but the second and third, ... do not. And if the first user logs off and on again, it's search also doesn't work anymore.

Anyway, still hopeful they will be able to reproduce the issue in their lab and escalate it to the product group.

Answer 4

Another update:

I spoke to soon :). The first user only has a working search if the logon is before the start of the "Windows Search" service, which we had set to "automatic (delayed start)". Today I started the server, waited for 5 minutes and logged on. Search didn't work, so I made a new procmon bootlog with the delayed logon and uploaded it to my support case with Microsoft.

Answer 5

Hi all, Latest update:

Hello Bart, team,>  > Got feedback from the PG, it seems they triaged our issue. For now our release date will be 3B ( so 2nd week for March ).> Since this is going to be on server edition it will be disabled by default – which means we need to install the update then apply a group policy that enabled the fix for the issue.>  > It will get automatically get enabled in 3-4 months.

@Joe Brugaletta I'm with @Benjamin Asllani on the Server 2019 Search. When we were still running Server 2019 it was working correctly.