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(198.4, 65%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJW%3C/text%3E%3C/svg%3E)
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.
![](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(57.599999999999994, 82%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EST%3C/text%3E%3C/svg%3E)
Unfortunately looks like server based OS is at the bottom of the MS pile for getting fixes out, they seem to be prioritising workstations. The windows 11 fix was back in June/July time so you’d think it would be fairly easy for them to port it over to windows 2022 server.
![](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(304, 60%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
It's a shame the search was never fixed. This problem is years old
![](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 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!
![](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(252.8, 80%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBA%3C/text%3E%3C/svg%3E)
Hi Bart, do you have some more insight on whats your scenario? I read in a post earlier that this issue seems Windows Server 2022 releated, not FSLogix, right? Also, what FSLogix Settings do you have set on your RDSH?
Thank you!
Hi, yes, FSLogix has nothing to do with the issue. The issue is purely Windows Server 2022 with RDSH role. Our test environment does not have FSLogix installed. It is a clean Windows Server 2022 install with no GPO's, domain join or anything except for Windows Updates installed. Our live production environments are Citrix CVAD with PVS and golden image running Server 2022. To much information to post here. Do you have any specific questions?
Hi Bart - Groeten! :)
I just did some more research on this. On your Blog post (https://www.nimble.be/gastblog-door-bart-een-reis-door-de-upgrade-van-microsoft-windows-server-met-citrix-pvs/) you mentioned some Settings regarding Windows Search GPOs on Server 2022 and that Windows Search breaks, as soon as RDSH Role is installed. Is Microsoft aware of that? Do your GPO settings have any impact on that? From your Blog post its not quite clear if the GPO settings happened before or after installing the RDSH role. Do you know the exact reason for this behaviour from Microsoft? Is there any information on the public release of the fix?
Also, in my environment there is not event ID 2 for Windows Search - also restarting the service after a user logged in has no impact and the search, allthough theres a edb in roaming, is not working.
If you set EnablePerUserCatalog = 1 the Outlook Search works even from the start menu and its added to the indexed places. However search for the users folder does not work as its not added to the indexed places. Either 1 nor 0 fix this, but removing EnablePerUserCatalog means no search at all.
Thank you for your work and your updates on this!
Ben
This is still broken in windows server 2022. Microsoft are aware as the fixes that went in to Windows 11 multi session were missed from 2022 and thus has to go through testing and validation before sign off as fixed. So there is no workaround at the moment apart from restarting machines and it’s a case of just wait for MS to release the fix.
This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
![](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(281.6, 45%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJY%3C/text%3E%3C/svg%3E)
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?
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 ... .
Hey Bart,
I find it sharp that you suspect I am from the Netherlands, and you are absolutely correct! I have read your guest blog on Nimble and found it to contain interesting information that is helping me in my adventure with RDS environments. This saves me from encountering some pitfalls that I no longer have to stumble upon.
A small side note that I am still curious about: the question of why you still use Windows Server (2022) as the operating system in RDS environments? Azure, of course, has the option to use Windows (10/11) Multi-user, but this seems to be a requirement for running it in the cloud. Therefore, I can understand that if you want to keep the environments locally hosted, you are obligated to use a Server OS. My current challenge is in making RDS environments that we host operational again. In many environments, the performance is below the benchmark, so I am trying to gain new knowledge in this area, including using tools like FSLogix & MSIX App Attach. I am also working on the AZ140 (Azure Virtual Desktop) certification to explore what is possible in the cloud.
![](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(278.4, 49%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJB%3C/text%3E%3C/svg%3E)
Bart, do you have any indication that this fix will work for server 2019 as well? We have 5 RDS hosts using 2019 and search doesnt seem to work on any of them. I've installed the Windows Search feature, ensured the Search service is set to start automatically and reinstalled Office 365. Not sure if you've noticed but the "Filter email" button on the toolbar is grayed out (Under the Search People / Address Book option).. thats my indicator that its not working. Indexing options shows 0 items indexed. We're also using FSLogix which I thought was the issue, but now I'm not so sure.. I did test the event ID 2 restart service option but that didnt seem to help either. And you mention it results in corrupt databases..?
Hi Joe,
Windows Search is working on Server 2019 with these settings (basically no Search Settings changed from default):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search]"CoreCount"=dword:00000001
![](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)
Thank you Bart for the updates !