search

JamesKindon / jkindon.github.io

https://jameskindon.github.io/jkindon.github.io/
Other
0 stars 1 forks source link

Windows Search in Server 2019 and Multi-Session Windows 10 #6

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

Windows Search in Server 2019 and Multi-Session Windows 10

Windows Search challenges in Server 2019 and Windows 10 Multi Session

https://jkindon.com/windows-search-in-server-2019-and-multi-session-windows-10/

mkools commented 2 years ago

There is yet another update from MS:

https://support.microsoft.com/en-us/topic/november-22-2021-kb5007266-os-build-17763-2330-preview-c9ba0c4c-c8b7-409a-8fac-a76ffae8f94f

Addresses an issue that causessearchindexer.exe to keep handles to the per user search database in the path below after you sign out: “C:\Users\username\AppData\Roaming\Microsoft\Search\Data\Applications\\” As a result, searchindexer.exe stops working and duplicate profile names are created.

With the same fix?

vincy1169 commented 2 years ago

Hi James, thank you for this post, it's very detailed and helped me a lot. I worked close with Microsofts to fix this exact issue. There are 2 preview fixes available right now to fix this issue. Both need to be installed on your system. Its KB5006744 and KB5007266.

AvrumFeldman commented 2 years ago

Hi James, Thanks for this thorough post on the innards of per user search indexing.

Just a piece of info I struggled to find documented at all anywhere on the internet that might come to good use. To rebuild the per use index we need to create a registry dword HKEY_USERS\<UserSID>\Software\Microsoft\Windows Search\RebuildIndex with value 1, on the next Windows search service restart the user index will be rebuilt.

tommls commented 2 years ago

Can this issue, if it exists within our Win2k19 Citrix CVAD 2103 XenApp servers, cause CPU to max out within the servers, and can it cause rdp logoff from any of these servers to fail with 'Please wait for the Windows Search...'?????? We don't have the Windows Search service enabled in Services but we do have 'enable Outlook search roaming' enabled in Citrix group policy. Only other thing I've seen is that the most CPU usage is with the System process, which sort of fits with all this herein. Thank you, Tom

jasonmccutcheon commented 2 years ago

Hi James, brilliant write-up. Thank you publishing this article.

We are embarking on our Server 2019 journey (so have the inclusive rollup pack with the Search Indexer fix). We are using the latest release of FSLogix. Whilst we continue to see the event ID 2 (where things go pear shaped), by the looks of things the associated handles under the Search Indexer are being released. I cannot see any of the other events you have referenced.

Subsequently when the user account logs back on it seems to re-attach to the same SID and files. Outlook seems relatively happy, but as we are running with a test account the results returned within Outlook are somewhat limited!

Is this something you/others have also observed post update? I am concerned we are seeing this event pop in - so hoping its a false positive.

TIA

Jason

dmutsaers commented 1 year ago

Am I correct in thinking we still need to implement the PowerShell scheduled task workaround in December 2022 to get Windows Server 2019 multi-session search in a working condition?

Dennis.

berryblack007 commented 1 year ago

Hi, I am having almost the exact same issue. We are using FSLogix to manage our RDS profiles. Two server 2022 host session servers. At logoff, seeing event ID 1, as opposed to 2, 'Windows Search Service indexed data for user 'domain\username' successfully removed in response to user profile deletion.' - Normal eventID I suspect as the profile is dismounted and removed at logoff... Window Search Service then needs to be restarted before we see eventID 326 and the users search .edb is mounted once again. Not sure if there is a Server 2022 patch for this?

dmutsaers commented 1 year ago

Why has this been completed? To my knowledge the issue still exists, even on Windows Server 2022, as it seems.

JamesKindon commented 1 year ago

Why has this been completed? To my knowledge the issue still exists, even on Windows Server 2022, as it seems.

Ah I was trying to close out open comments statuses in GitHub issues (what is used for comment tracking) as I had not been getting notifications on comments - might need to take a different approach given it appears you did - always learning how this platform works

hZtb543 commented 1 year ago

berryblack007: Hi, I am having almost the exact same issue. We are using FSLogix to manage our RDS profiles. Two server 2022 host session servers. At logoff, seeing event ID 1, as opposed to 2, 'Windows Search Service indexed data for user 'domain\username' successfully removed in response to user profile deletion.' - Normal eventID I suspect as the profile is dismounted and removed at logoff... Window Search Service then needs to be restarted before we see eventID 326 and the users search .edb is mounted once again. Not sure if there is a Server 2022 patch for this?

We are also tackling the Windows Search issue in a brand new and clean WS2022 TerminalServers+FSlogix environment (not Citrix but Parallels RAS). In our environment we also get only the ID 1 event after logout. Restarting the service at this point doesn't help. After Logon of a new user no events regarding the search are logged. Restarting the service after a new logon triggers all the event ids. It seems that the search service does not recognise that there is a new userpartition added to the server via FSlogix.

What I'm not shure about are the registry keys (located under HKEY_LOCALMACHINE\SOFTWARE\Microsoft\Windows Search). I left the as windows sets them after installing the TS server role EnablePerUserCatalog set to 1 EnablePerUserCatalogFileIndexing_ set to 1

When EnablePerUserCatalog is set to 0 as mentioned in this article no restart of the service is needed but the profile related search index does not roam. Thats also not exactly what we want.