Support for Server 2019 and Office 2019 Search Roaming RRS feed

  • Question

  • Hi,

    is Outlook 2019 on Server 2019 supported for Search Roaming in Multi-User Search mode ?


    Thursday, July 11, 2019 9:58 AM

All replies

  • This should work and is supported. I've reached out to the dev team to see what their experience has been with this.

    Friday, July 12, 2019 2:02 AM
  • Installation, configuration and search hooking seems to work - according to process monitor and logs.
    But outlook does not start indexing, and shows indexing status loading forever.
    Windows update status is July 2019 and latest Office 2019 build.
    Anybody else?
    • Edited by M.Eckerle Friday, July 19, 2019 6:45 AM
    Friday, July 19, 2019 6:30 AM
  • Hello, 

    We are experiencing same behavior. Everything is working fine on WS2016, but not on WS2019. Same situation as M.Eckerle.

    Tuesday, July 23, 2019 4:59 PM
  • Randy, can you share some more troubleshooting tipps regarding the issue?
    Wednesday, July 24, 2019 9:50 AM
  • Submitted MS Support-Case yesterday. Support confirmed support for Server 2019 Multi User Search. Going through KB "Outlook Search Troubleshooting Guide" again...will keep this thread updated.
    Friday, July 26, 2019 6:35 AM
  • I too am having issues with 2019 RDSH with Office 2019 - Any update please ?
    Monday, August 19, 2019 7:12 PM
  • Hello James,

    Microsoft Now Supports Office 365 ProPlus on Windows Server 2019 (and FSLogix)

    The most common setup issues are covered in the "Outlook Search Troubleshooting Guide" for FSLogix. 

    If you are still having issues setting up FSLogix with Office 365 and Windows Server 2019, please open a ticket from:

    - Micah Adamson

    Monday, August 19, 2019 8:36 PM
  • Thank you for taking the time to reply - after looking at the guide I created a ticket.

    Support request number: 119081921002460

    I tried to update the ticket online with addtional info, but when I do I get sent to azure and get the following error on the azure portal.  Do you know if I need to create another ticket with such an error ?

    Sorry, some error occurred while processing your request. Here is the tracking id edd63b86-3660-4af5-9e41-726795027ed3. Please contact Microsoft Support

    Monday, August 19, 2019 10:15 PM
  • Issue still not solved for us. Teams meeting with MS Support scheduled for today...
    Tuesday, August 20, 2019 8:46 AM
  • Thank you for the update - I appreciate you are probably very busy, but if you could find the time to update this thread with what you find, I would be most grateful!
    Tuesday, August 20, 2019 8:51 AM
  • I am having the same issue but Server 2019 with Outlook 2016. Indexing sits on loading forever. Opened a ticket and have been emailing back and forth but no resolution yet.  Ticket# 119081924004385
    Thursday, August 22, 2019 3:48 PM
  • Hello Mike,

    Thanks for letting us know you are having the same issue. I'll make sure that someone takes a look at your case today. Outlook search issues with FSLogix are most often caused by configuration problems between the many variables involved in setting it up. However, we're involving the DEV team too to make sure that there isn't a problem in the code.

    Thanks for your patience as these issues can take a while to find the cause due to the complexity of variables.

    - Micah Adamson


    Thursday, August 22, 2019 4:58 PM
  • Thank you Mike.

    ...btw, no resolution for us so far.
    We went through all known troubleshooting steps again. Case still open.

    Thursday, August 22, 2019 5:10 PM
  • Hello Mike,

    is there an update to your Ticket ? Did you find any solution to solve this Issue?

    - Tobias Kothe

    Wednesday, September 11, 2019 12:34 PM
  • Our case is still open..."the dev team is still working on this issue"

    - Matthias Eckerle
    • Edited by M.Eckerle Wednesday, September 11, 2019 12:51 PM
    Wednesday, September 11, 2019 12:51 PM
  • FYI: The OneDrive DEV team and FSLogix DEV team are still investigating this issue. Sorry it's taking so long.
    Wednesday, September 11, 2019 5:23 PM
  • Same issue here. Multi-user search does not work in Outlook 2013 on Windows 2019. Works fine in Windows 2016.

    The primary reason we're looking at Windows 2019 is files-on-demand, so that large SharePoint libraries synced to OneDrive don't eat up all FSLogix VHDs

    Friday, October 4, 2019 9:18 PM
  • Any News on this?
    Tuesday, October 15, 2019 7:07 AM
  • So here is my update and my two cents on this...
    MS support finally (after 3 month!) told us to use the "new" built-in user-based search functionality in server 2019 which seems to come with the rds role. So we have to use fslogix profile container with search roaming by fslogix disabled for now. The search database is stored in AppData\Roaming for each user.
    This is NOT reliable at all by today. Every third or fourth logon causes errors regarding search container mount and outlook indexing will break until the search service is restarted. I'm really curios why there's no documentation for user-based search functionality in rds 2019 and how on earth MS wants to support O365 on server 2019 without proper search functionality for outlook. The situation is not satisfying at all. I think we have to wait for updates.

    Any other thoughts or suggestions?

    Sunday, October 20, 2019 4:19 PM
  • The appdata per user search is enabled by default depending on the SKU. The RDSH variants of server 2019 will use the new search method. At this time, FSLogix is going to let the built in Windows search split the database instead of using the same method as we have in the past. This should provide for a more reliable search experience since FSLogix will then only have to roam the DB And the metadata. In profiles, the search database should roam correctly, but with ODFC, we are working on the feature to roam the new search database.

    Are you seeing the forever indexing issue with FSLogix profiles? And have you seen it without FSLogix on the box (Are you sure it's the per user Windows Search)?
    Monday, October 21, 2019 10:35 PM
  • @DALLINLMAG Not sure who you are addressing, but I will answer. We have gotten the perpetual indexing issue with FSLogix Search Roaming on RDSH 2019, with Outlook 2016. We ended up having to disable Search indexing of Outlook all together, with group policy, to stop Windows Search locking the OST file and crashing Outlook.
    Monday, October 21, 2019 10:41 PM
  • Any updates on this?
    Outlook search is still not working with latest windows and fslogix bits!!!

    First Login -> new container -> Outlook Cached Mode -> Index working -> Logoff

    Second Login -> existing container -> Outlook Cached Mode -> Index database not mounted ->
    Search in Outlook not working -> Logoff

    Restart RDS Host

    Next Login -> existing container -> Outlook Cached Mode -> Index working again -> LogOff

    Next Login -> existing container -> Outlook Cached Mode -> Index database not mounted -> Search in Outlook not working


    Friday, December 6, 2019 1:59 PM
  • We have the same issue (Server & Office 2019).

    I got the 'Indexing Status' in Outlook to report back. After manually creating %AppData%\FSLogix\WSearch directory.
    The service -- don't know which one -- seemingly failed to create it.
    Immediately after creation, the typical WSearch files were created. I also ran icacls /reset /t, just as the "Search" log says.

    And still, even after rebooting and restarting and double-and-triple checking everything. The status is still the same.
    The crawler logs event 3037 (Application/Search) with an HRESULT of 0x80040d0d for mapi16://SID.

    The troubleshooting guides (both FSLogix and Outlook) don't help.

    Friday, December 6, 2019 2:57 PM
  • @MikeHSB I haven't heard of Outlook crashing from Search. Is it a hard crash or something else? And are you using FSLogix RoamSearch? If not, then FSLogix should not be changing how Outlook and Windows Search interact. It should just be managing the storage location. 

    @M.Eckerle With the new search for server 2019, I have seen some cases where it fails to load when the user logs in the second time. I am not sure what is causing it, but make sure that when the user logs off, there are no handles held under this path (or anything under roaming really): C:\Users\<Username>\AppData\Roaming\Microsoft\Search. I am not certain, but I worry that search is holding handles and it makes it fail when the user logs back in. We successfully use the new search here with profiles, but usually, we aren't logging out and in quickly. Can you check and see if there are held handles when the user logs in the second time? 

    @velartis-md If you are using a terminal server version of Server 19, then we shouldn't be seeing the Wsearch directory at all, as FSLogix won't be handling the search database location directly. What is your current configuration? 
    Friday, December 6, 2019 9:59 PM
  • @DALLINLMAG All of the info is in my ticket if you want to review it. I think they closed it for now.

    Ticket #119081924004385

    Friday, December 6, 2019 10:35 PM
  • Alright, we have Search in Outlook working now. Just the "forever indexing status" remains, which can be ignored.

    Roaming of any sort may be an issue. FSLogix ODFC either fails or simply does not roam the search databases.

    Which after all, may be perfectly fine. Since just as M.Eckerle already mentioned, nothing of the new behavior regarding Server 2019 is documented.

    In the end, this seems to be the case:
    FSLogix Search Roaming on Server 2019 RDSH is not supported. In the sense that, FSLogix intentionally does nothing.
    Instead the undocumented per-user search database feature of Server 2019 is used instead.

    What does and doesn't work with that, is anybodies guess.
    • Edited by velartis-md Thursday, December 12, 2019 1:36 PM
    Thursday, December 12, 2019 1:35 PM
  • @MikeHSB Thanks for giving me the ticket info. If you have been seeing Outlook become unresponsive, may I ask what plugins you have enabled? Because if FSLogix search is disabled, then we should not be injecting the process and messing with Outlook at all. That can be verified using Process Explorer. 

    @velartis-md It does seem strange when you put it that way! The reason the search feature was developed at FSLogix was because Windows search didn't support roaming natively. With Server 2019, it now supports roaming of the search database. So we feel it will be better overall to let Windows Search handle the databases, since that's their wheelhouse. I'm not sure why there is so little, if any, documentation.

    The server 2019 roaming search should work, but we have found an issue where handles to the database are being held after the user logs off. It's being worked on by the Search team, but for me, that is the issue causing the infinite indexing status message. I will update the group when I have more information. 

    Monday, December 16, 2019 7:29 PM
  • Excerpt from the "Office Container registry configuration reference" / "Profile Container registry configuration reference":

    "Windows Server 2019 and Windows 10 Enterprise multi-session support per user search. RoamSearch should not be enabled in these environments."

    However, I can't get Search Roaming to work reliably, it only works on the first login. 😥

    Best regards,

    Saturday, January 25, 2020 7:04 AM

  • The server 2019 roaming search should work, but we have found an issue where handles to the database are being held after the user logs off. It's being worked on by the Search team, but for me, that is the issue causing the infinite indexing status message. I will update the group when I have more information. 

    @DALLINLMAG I think I have the same issue with Windows Server 2019 Roaming Search. It works the 1st time an user logs in, but after an user logs out, the Outlook search fails. If the server (or the Windows Search service) has been restarted, Outlook search works again.
    It would be nice if this could be fixed.

    Best regards,

    Sunday, January 26, 2020 6:28 AM
  • Got the exact same problem - It works the 1st time an user logs in, but after an user logs out, and back in the Outlook search fails. We have not enabled RoamSearch in the FSLogix settings, and lets Windows 2019 multi-session support (try) to handle it.

    Would be nice with a solution for this @DALLINLMAG


    Sunday, January 26, 2020 9:29 AM
  • Update..

    I installed the January 23, 2020—KB4534321

    This updates addressees a couple of things regarding windows search.

    "Addresses an issue that causes the Microsoft Windows Search Indexer (searchindexer.exe) to add or repair required access control lists (ACLs) without checking if ACLs exist."

    After installing this I have successfully done several logins without the index database breaking!

    Will continue the testing. Would also be nice if others that tests this update also reports their experience.

    We are running Win Server 2019 - 1809


    • Edited by Fredrik_E Sunday, January 26, 2020 12:27 PM Spellings
    Sunday, January 26, 2020 10:50 AM
  • Hi Frederik,

    I just installed KB4534321, and it looks like the succes rate is a bit higher, but by no means stable.

    Best regards,
    Sunday, January 26, 2020 12:27 PM
  • Dear Frederik,

    1. I disabled all settings regarding Windows Search, recommended by the FSLogix Outlook Search Troubleshouting Guide.

    2. I didn't configure the reg key. Did I miss the memo on that? However, I've added it now.

    Everytime an user logs out, I receive the following error in the event log:

    Log: 'Application' Date/Time: xx/xx/xxxx xx:xx:xx PM
    Type: Error Category: 0
    Event: 2 Source: Microsoft-Windows-Search-ProfileNotify
    Unable to remove Windows Search Service indexed data for user 'domain\user' in response to user profile deletion. Error code 0x80004002. Interface not supported.

    When an user logs on, loads of errors in the applcation log from the "data gatherer", and some other error from Outook mentioning "
    0x80004002." The errors are in Dutch, I don't know the english equivelant.

    The result is the same, a corrupted index, and a failed Outlook search.

    If I rebuild the index, it works one time again.

    Best regards,

    Sunday, January 26, 2020 1:36 PM
  • Hi,

    Same problems here:

    Windows Search changes in Server 2019 RDS

    Best regards,

    Monday, January 27, 2020 6:33 AM
  • Hi, 

    There is same issue with break searching on Windows Server 2019 + FSLogix. I tried to debug it:

    My enviroment

    • 2x RDSH Windows Server 2019-1809(17763.1012) + FSLogix 2.9.7237.48865
    • 1x RDCB Windows Server 2019-1809(17763.1012)
    • FSLogix - Profile container, roaming search was turned off because WSR2019 should handle it by yoursefl but there is bug
    • All servers fully updated with latest CU(KB4534321)
    • Office365 ProPlus 64bit - 16.0.12430.20172

    I tried turn off FSLogix and use UPD but it was same. There is not difference so the issue is not in FSLogix but in Windows Server 2019 and how it handle it.


    1. There is SearchIndexer.exe process wich run as "NT AUTHORITY\SYSTEM". This process accessing index database for every user. It is reason why user doesn't need to has access to the folder where index is(in his profile). It is not necessary. SearchIndexer.exe accessing it as "SYSTEM."
    2. There is SearchProtocolHost.exe process for every users which run with user rights. It is child process of SearchIndexer.exe. This process indexing data(Outlook ost file) but it is not necessary for searching. Process starts with Outlook and if all data were indexed, the process is closed. Searching in Outlook works without this process. When new email arrived or after several search, process starts.


    When user log off, vhdx file is deatached from server but process SearchIndexer.exe has files from user profile open and there is error. Files are not accessible because are not presented.


    Restart Windows Search service(SearchIndexer.exe) after any user log off - inaccessible files are released. It also closed all child process for every user but Outlook starts it by yourself when need it.


    • Edited by Tomas Cinki Thursday, February 6, 2020 9:49 AM
    Thursday, February 6, 2020 9:41 AM
  • I have the exact same issue as Tomas.

    Same RDSH/FSLOGIX version

    Search roaming via native Windows 2019 search.

    Logging off the user generates the following error messages:

    Search-ProfileNotify Event ID 2 Errorcode 0x80004002


    Search: eventid 3057/3029/3028/3058/3057/3029/3028/3058

    When the user logs back in windows search no longer works. (unable to fetch indexing information for outlook)

    Restarting the windows search service triggers these errors:

    ESENT eventid 482 (unable to write to appdata\roaming windows search EDB file)

    ESENT eventid 483 (unable to write shadow header error 1022)

    ESENT eventid 104 (Database engine stopped session 1 with error -1022

    Then after starting the window search service again, a new session is started, it runs some recovery on the user EDB file and things are back to normal until you log off again.



    Thursday, February 6, 2020 3:20 PM
  • Hi JeWi, 

    There are same event's for me:

    When user log off:

    • Seach-ProfileNotify, 2, -Unable to remove Windows Search Service indexed data for user...
    • User Profile Service, 1534 Profile notification of event Delete for component {DE3F3560-3032-41B4-B6CF-F703B1B95640} failed, 

    When same user log on:

    • Search,3059The update cannot be initialized....
    • ESENT, 482,416,492
    • Search 7040 -  The search service has detected corrupted data files in the index...
    • and so on...

    My solution(not yet tested in production)

    I created scheduled task..trigger:when event Seach-ProfileNotify, 2, action: powershell.exe Restart-Service WSearch.

    It works. No more event like this. Restarting search service close all files from deatached vhdx file(profile container) as I wrote in my post above.

    • Proposed as answer by John Everyman Friday, February 7, 2020 9:29 AM
    • Unproposed as answer by John Everyman Friday, February 7, 2020 9:30 AM
    • Proposed as answer by John Everyman Friday, February 7, 2020 9:42 AM
    Thursday, February 6, 2020 10:07 PM
  • Scheduled task powershell.exe Restart-Service WSearch on Microsoft-Windows-Security-Auditing event ID 4647 is doing the trick for me.

    Friday, February 7, 2020 9:33 AM
  • Do we have any "REAL" solution in sight here?  
    Friday, February 7, 2020 7:34 PM
  • Hi,

    When the task triggers at user log off and the WSearch restarts, I get these error messages:

    ESENT eventid 482 (unable to write to appdata\roaming windows search EDB file)
    ESENT eventid 483 (unable to write shadow header error 1022)
    ESENT eventid 104 (Database engine stopped session 1 with error -1022)

    Don`t you get these?

    I don`t get any errors at user log on.



    Sunday, February 9, 2020 1:21 AM
  • Hi Fredrik, 

    my answer is simply no. I don't see this error but it was just test from my side. It isn't in production.

    What is your environment? It is not working when you restart service for others who are still logged?

    Monday, February 10, 2020 11:05 PM
  • Hi Tomas,

    Restarting the service does the trick however I'm not positive I want to do that in a production scenario :)

    Hopefully this will get patched soon.



    Tuesday, February 11, 2020 9:30 AM
  • Hi,

    The solution seems to work fine (WSearch restarts on Event Search-ProfileNotify ID 2), and the search(database) works as it should after logging on\off between different RDSH server in the farm.

    Other users that are still logged on, does noe seem to notice the restart of the service when a user logs off.

    But every time a user log off, the mentioned events are logged.

    So technically it works fine, but would like to get rid of the error events.

    (This is of course just a temporary solution until Microsoft hopefully soon comes with a solution\fix\patch..)



    Wednesday, February 12, 2020 11:01 AM
  • @Frederik,

    sure, this works...but the personal search DB is gone after relogon...under W2K16 you will see a WSearch folder. Under W2K19 the edb files are under %appdata%\Microsoft\Search\Data\Applications. Mount the VHDX File and you see nothing...

    Regards C-M

    Friday, February 21, 2020 12:55 PM
  • @clmaier

    No, the search db is not gone! It get attached at next logon and the preciously indexes works fine.

    "SearchIndexer (3560,D,50) S-1-5-21-689457963-1845298519-788813119-28645: The database engine attached a database (2, 'C:\Users\XXXXXX\AppData\Roaming\Microsoft\Search\Data\Applications\S-1-5-21-689457963-1845298519-788813119-28645\S-1-5-21-689457963-1845298519-788813119-28645.edb). (Time=0 seconds) "

    Have you removed\disabled all that regards search roaming in the FSLogix GPO`s for your Windows 2019 setup?



    Monday, February 24, 2020 11:04 AM
  • Hi Fredrik,i think so,

    under FSLogix GPO

    Administration Templates\FSlogix\Enable Search Roaming -> Disabled

    Administration Templates\FSlogix\Enable Search Roaming\Office 365 Containers\Store Search Database in Office 365 container -> Disabled

    We are using XenApp 1912 (UPM)...i would have expected that the EDB Files part of the O365 (not the same as in W216RDS) but i cannot find anything in VHDX

    Regards C-M

    Monday, February 24, 2020 12:08 PM
  • It will not be a part of the 365 container when these policies are disabled.

    In Win 2019 Microsoft has changed the search. By design each user has now their own search db.

    It will be located on the FSLogix Profile container:

    C:\Users\XXXXXX\AppData\Roaming\Microsoft\Search\Data\Applications\"User Sid"\...


    Monday, February 24, 2020 12:42 PM
  • Hi Fredrik,

    i know the location, but i only want to use O365 Container from FSLogix. Not the Profile Container. With W2K16 RDS a mix of CITRIX UPM and FLogix O365 container is possible. In this personal search DB (Outlook) wil be saved in the WSearch folder and this is part of the O365 Container of FSLogix. The support said to me in case of W2K19 and using O365 Container to disable these to sections.

    Regards C-M

    Monday, February 24, 2020 12:49 PM
  • Hi,

    I don`t think this will work with O365 container in Win 2019. Windows Search database has changed from a common per machine DB in 2016 (C:\Programdata) to per user DB in 2019 (..\Roaming\Microsoft\Search\..). This is not taken care of in current version of FSLogix. 

    I guess you can roam the new location of the search DB with the Citrix profile. This will of course make the profile bigger, and slow down the login process.. Not ideal.



    Tuesday, February 25, 2020 2:22 PM
  • ** BUMP **

    I've been following this thread and applied work around as suggested some time ago - Windows Event Log -Application - Event 2, Search Service restart. This has been working for most users but has been giving inconsistent results.

    Has anyone here got any new information regarding an actual fix to this issue? Doesn't anyone know if Microsoft is addressing the issue, and will there be any changes to the search services in the upcoming updates?


    Thursday, April 9, 2020 2:50 AM
  • Same issue for us on latest Windows 2019 (cumulative 2020-04) and FSLogix (2.9.7237.48865) versions.

    We ended up using the WSearch restart PowerShelll script from Task Scheduler work around for a little while, but found this too unreliable so we rolled back to W2016 for our Citrix Hosted Desktops on CVAD 1912 LTSR. We will not be moving users to W2019 until this issue is resolved. Has anyone had any luck fixing this?
    Wednesday, April 29, 2020 5:57 AM
  • We have a Scheduled Task that starts on EventID 2 -  Search-ProfileNotify

    Triggers basically every time a user logs off.  Not the "prettiest solution", but it works stable in our environment. (Of course as a workaround until a fix is released..)



    On An Event

    Log: Application

    Source: Search-ProfileNotify

    Event ID: 2



    Restart-Service WSearch

    Thursday, April 30, 2020 10:18 AM
  • Hi @all,

    there is a new version for downloading avail....but i found no changelog what was changed.

    The new version is "FSLogix_Apps_2.9.7349.30108" instead of "FSLogix_Apps_2.9.7237.48865"


    Thursday, May 7, 2020 10:51 AM
  • We have the same issue. RDS 2019 and Full Profiles.

    I have tried the "old" way with fslogix handling the search roaming resulting in all kinds of errors and corrupted search indexes and what not.

    @clmaier I think this is an issue with search in 2019 and not with fslogix.


    Wednesday, May 13, 2020 1:00 PM
  • What a frustrating issue, we really need Microsoft to resolve this.  We came across this problem in our test environment for Citrix Windows Server 2019 deployment.  We'd like to deploy a new customer on 2019, but this is giving us pause.  We have FSlogix profiles with roamingsearch set to 0 (disabled)

    Our indexing shows 0 items indexed, and won't even give the option to index user profile folders, just Outlook.  The restarting of the service doesn't appear to change anything.  Outlook does show results when you search, but we have no options to select folders with the search GUI, or does it look like its working.

    - Ryan

    Tuesday, May 26, 2020 3:04 AM
  • I'm am just about to roll out a 2019 RDS environment with FSLogix and came across this post.  I did some research and could not find anything mentioned that this was ever resolved.  However, the thread went quiet so, was it ever fixed or are all of you just running production environments with the scheduled task to restart the Wsearch service?
    Monday, June 1, 2020 7:29 AM
  • We have a microsoft open with this issue.

    The indexing isn't working correctly for most of the users in one of our environment.

    Tuesday, June 2, 2020 12:42 PM
  • We have a microsoft open with this issue.

    The indexing isn't working correctly for most of the users in one of our environment.


    please send me the ticket number, I will open a premier support ticket on this with reference to your case number.



    Tuesday, June 2, 2020 6:33 PM
  • We are running 2019 RDS/Citrix, roaming profiles and to delete those profiles on logout.   We had originally gotten all the warnings about how it could not remove profile on logout until we added GPO to exclude the AppData\Roaming\Microsoft\Search\Data\Applications.  This worked for a few, but now we are getting event ID 2: Search-ProfileNotify : Unable to remove Windows Search Service indexed data for user 'xxx' in response to user profile deletion.  Error code 0x80004002.   No such interface supported

    Next time user logs in, they have the profile remnants there with the search folders there, and they get a new .000, .001 profile and so on.   I now have 20+ users with 40+ profiles all filling with the orphaned search folders.   I am going to try adding the Windows search service restart on logout - hoping that releases any lock to let the user-profile service to delete it all.   What a mess.   Our 2019 RDS/Citrix rollout is on hold now.

    Friday, June 5, 2020 8:54 PM
  • Hi Frederik,

    Do you still have this workaround in place? I've frozen my 2016 -> 2019 migration plans until this issue is solved and I don't see any progress on it so far.



    Monday, June 29, 2020 8:18 AM
  • Hello

    We have the same case, search error at logoff, event ID 2, works fine after restart of service.

    Any news about the case with MS about this ?


    Thursday, July 2, 2020 1:55 PM
  • Hi, 

    I suspect that MS will never fix the issue. The issue has been know for more than 6 months now, so either it can't be fixed, or Microsoft has it so far down on the list of bugs that it will still be a while before we see a fix.

    I have described both the workaround with the event id 2 and another workaround in a recent article on my blog.

    Friday, July 10, 2020 6:27 PM
  • I opened a case about it, but they even didn't know what I was talking about. They suggested to disable search roaming in FSLogix group policy, which I already did of course.
    Friday, July 10, 2020 10:37 PM
  • With no success after trying everything in the thread, and in other online forums earlier this year to resolve the searching issue in Server 2019. I decided to come up with a solution that works for us and our supported clients that I'd like to share.

    Please note that this solution won't index the users profile container.

    Hopefully it helps other admins feeling the frustration:

    • FSLogix, disable multi-search on the hosts - it's currently known that FSLogix search doesn't work with Server 2019.
    • Disable Windows Server 2019 multi-user mode (Registry value below).
    • On our RDSH Servers we turned off all indexing locations. We are only using the Windows Search service to receive results from Network Share Indexes on our file servers.
    • Now we let the latest version of Outlook handle the searches of the OST/PST files (Our Registry settings are below). Searching in Outlook is fast but the only issue I can see is that Outlook doesn't highlight the searched text in yellow highlight which I'm thinking is a Windows Search Service/Outlook feature, nonetheless Outlook search works well and the users are happy.

    Though this is working for us, I haven't yet performed a test with the latest version of FSLogix, Windows Server 2019 and Outlook with the registry value "EnablePerUserCatalog"=0 (Disabled).

    Could it be possible that with this new 2019 search feature disabled that FSLogix will handle the searches correctly again? I will get around to testing this soon, but if anyone else has the time or has already tried this and would like to share that would be great!

    To disable Server 2019 multi-user mode searches:

    Key path SOFTWARE\Microsoft\Windows Search
    Value name EnablePerUserCatalog
    Value type REG_DWORD
    Value data

    0x0 (0)

    Using Outlook to search:

    Key path SOFTWARE\Policies\Microsoft\office\16.0\outlook\search
    Value name defaultsearchscope
    Value type REG_DWORD
    Value data 0x2 (2)

    Key path SOFTWARE\Policies\Microsoft\office\16.0\outlook\search
    Value name disabledownloadsearchprompt
    Value type REG_DWORD
    Value data 0x1 (1)

    Key path SOFTWARE\Policies\Microsoft\office\16.0\outlook\search
    Value name SearchResultsCap
    Value type REG_DWORD
    Value data 0x3E8 (1000)

    Key path Software\Microsoft\Office\16.0\Outlook\Options\General
    Value name PONT_STRING
    Value type REG_SZ
    Value data 53

    Monday, July 20, 2020 4:02 AM
  • Hi,

    I dont understand how you force using Outlook search instead of Windows Search...

    Registry Outlook key seems doesnt force to use integrated outlook search...

    • Edited by frhell Wednesday, July 22, 2020 11:26 AM
    Wednesday, July 22, 2020 11:26 AM
  • Unticking Outlook from the indexing locations for the user seams to enable Outlook search. The Outlook registry keys/values posted are the settings we use for the end users to make it function the way we want it too.
    • Edited by DavidLee85 Sunday, July 26, 2020 11:29 PM
    Sunday, July 26, 2020 11:26 PM
  • Did you give it a test to see if FSLogix end up handling the searches 
    Wednesday, August 26, 2020 4:34 AM
  • Hi,

    I have described a couple of workarounds to get a reliable Search Roaming in WS2019 with FSLogix:
    Thursday, September 3, 2020 5:13 PM
  • Well I'm pleased to say I finally got this working. Just disable FSLogix search roaming and enable the per user search index (So don't add the EnablePerUserCatalag = 0 registry).

    Then with Powershell I push a scheduled tasks, which restarts the Search Service upon event ID 2 being logged. This works around the bug MS needs to solve.

    If anybody is interested in the script I've posted it here:

    Credits go to xplantefeve for providing the script.

    Also, if you go to file, options, search, indexing options you will see 0 items indexed, indexing complete. This might seem like a fault but this is correct. Since the Windows Search service can't interact with the local desktop and the catalog is per user. So the correct way to see if it's working is to click the search bar. Then click Search Tools > Indexing status.

    Wednesday, September 9, 2020 8:48 AM
  • Anyone verified with latest Fslogix?

    Sunday, November 22, 2020 7:23 PM
  • doesn't seem to

    have not tried any of the above - just broken FSLogix out of the box and let it rip with Office Containers and still have users with half baked search or no search at all and Outlook stuck at Loading when checking the index status 

    2019RD/2019 Core DC/Office 365


    'here's your new car wheel is wonky and the engine sometimes wont start for no reason but we may fix it before the next Armageddon' 

    Monday, November 23, 2020 7:29 PM