This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(236.8, 52%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EB2%3C/text%3E%3C/svg%3E)
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.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(6.4, 48%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMR%3C/text%3E%3C/svg%3E)
We have the same problem on all our terminal servers. Every time we log in we restart the search service.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(83.2, 80%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJ%3C/text%3E%3C/svg%3E)
Our users are suffering from this issue as well. Following here hoping soon for notification that Microsoft has fixed this.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(118.4, 56.00000000000001%, 21%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EHV%3C/text%3E%3C/svg%3E)
Wir haben das Problem nach wie vor, nur wenn der Cache Modus aus ist scheint es zu funktionieren. Hoffentlich gibt es bald eine Lösung von Microsoft dafür, dafür zahlen Kunden so viel Geld für ein fehlerhaftes Produkt... irgendwie enttäuschend ..... Qualität ist das nicht leider.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(163.2, 40%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPV%3C/text%3E%3C/svg%3E)
No new development on this? we have 1000 users with these problems
Doesn't seem to be working for us either.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(102.4, 20%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EE%3C/text%3E%3C/svg%3E)
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)
KIR feature flag is required to activate the preview fix included in KB5035857 until Microsoft release this as GA at some point in the future. You may need to create the registry path "\Policies..." as it may not already exist.
I installed this fix and add the registry key. but still its not working :(
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 51%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMK%3C/text%3E%3C/svg%3E)
I have tested this fix. New image built 2022 with Cvad 2203 cu4, latest fslogix version and clean profile. Doesn't seem to work indeed. In Outlook going to search tools > indexing status it hangs on loading. On server 2019 which we run in production it works fine.
However, when I restart the search service after logging on it suddenly starts to work. So that's probably the workaround here.
As for that fix I don't think it does anything. Or the registry key is wrong or both. I will test it tomorrow with and without the key with this workaround.
We need 2022 for the new teams which is currently broken on 2019. So very nice catch 22 here. 2022 without indexing, or 2019 without new teams.
we are having exactly the same. We need the new teams running, but for that we need to upgrade 415 servers, but we go from one problem to a new problem. Microsoft really needs to get his shit together, this is a very bad situation, and our customers are not very happy about it
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(179.20000000000002, 33%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBV%3C/text%3E%3C/svg%3E)
Hi.
We have 3 separate Citrix environments of which 2 have Office and the new Teams, all running Server 2022 (And the latest FSLogix) and search indexing has been working correctly since installing the update and activating the KIR with the registry entry.
I think there are a lot of others who also have it working, so strange that is not working for you ... .
yea, but it seams i am not the only one where it is not working. I installed the update, and added the reg key, rebooted server, we are only using remote desktop, and no Citrix, but i don't think that should matter since it is a windows issue, and not citrix
True, on a clean test system, all was working fine untill I added the RDSH role (which activated Windows Search and set the per-user search database entry in the registry). After installing the update, creating the registry entry and rebooting, it all worked fine.
do you have something special in your FSLogix policy about the search, i have roam search disabled
No, nothing special, I have the same entry but if you read the FSLogix documentation, some of those functionalities have been removed. FSLogix is Microsoft now, so they also completely removed the old way (search global and take out the user piece (at least for Server 2019 and 2022)).
I would assume the same fix is in the April patch Tuesday update? Is there some way to confirm the fix is active?
Btw my Eventlog shows these errors, might be related or not:
Event ID: 34 - Failed to get Crawl Scope Manager with error=0x80004002
Event ID: 35 - Failed to determine if the store is in the crawl scope (error=0x80004002).
i have these errors in my logfiles to
I get those errors every time I start Outlook. But then when I restart Windows Search service the error is gone and search indexing works. Next, when I logoff and log back on it's broken again and I have to do the same thing.
I think we might have some different issue I'm not sure. Workaround could be to do a restart wsearch service everytime this error comes up in the eventlog.
yes, but that is the problem we are talking about. Search not working after a user logs in, and restarting the servers solves it. But i can not do a service restart everytime a user logs in on 415 servers. but this is the original problem we are having
It doesn't seem to be working for us either. We also have the Crawl Scope errors so perhaps it's something different in our setup as well.
Could be, but my setup is pretty basic. Nothing special.
At this point it's only confirmed working for Bart right, nobody else?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(131.20000000000002, 64%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPM%3C/text%3E%3C/svg%3E)
I have the issue, same errors in the eventlog. I did not test the key because,
I don't think the error 34 en 35 are related. Because I get those on our 2019 prod env as well. And indexing there works fine. So I guess everybody gets these.
Anyway we'll just have to live with the issue. We are moving to published apps anyway and Outlook is only used for mail enabled published apps.
No they are not present on server 2019 for us, in several different farms all same configuration as 2022. This issue is strictly a 2022 issue AFAIK.