Esent ошибка 482

svchost (2544) TILEREPOSITORYS-1-5-21-1454471165-1303643608-839522115-2281: The database engine stopped the instance (7) with error (-510).

 
Internal Timing Sequence: [1] 0.000, [2] 0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6] 0.000, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000, [11] 0.000, [12] 0.000, [13] 0.000, [14] 0.000, [15] 0.000.

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.

• 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

    Friday, July 19, 2019 6:45 AM

• Hello, 

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

• Randy, can you share some more troubleshooting tipps regarding the issue?

• 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.

  • Edited by
    Micah AdamsonMicrosoft contingent staff
    Monday, August 5, 2019 7:34 PM
    Add link
  • Proposed as answer by
    Micah AdamsonMicrosoft contingent staff
    Monday, August 5, 2019 7:34 PM

• I too am having issues with 2019 RDSH with Office 2019 — Any update please ?
• • Edited by
    Micah AdamsonMicrosoft contingent staff
    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

• Issue still not solved for us. Teams meeting with MS Support scheduled for today…

• 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!

• 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

• 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

• Thank you Mike.

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

• Hello Mike,

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

  — Tobias Kothe

• 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

• FYI: The OneDrive DEV team and FSLogix DEV team are still investigating this issue. Sorry it’s taking so long.

• 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

• 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 AppDataRoaming 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?

• 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)?

• @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.

• 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

  Thanks!

• We have the same issue (Server & Office 2019).

  I got the ‘Indexing Status’ in Outlook to report back. After manually creating %AppData%FSLogixWSearch 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.

• @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>AppDataRoamingMicrosoftSearch. 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? 

• @DALLINLMAG All of the info is in my ticket if you want to review it. I think they closed it for now.

  Ticket #119081924004385

• 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.
  (Related: https://social.technet.microsoft.com/Forums/en-US/e87a25c5-71b8-412a-ba82-b7fa07a7363b/windows-search-changes-in-server-2019-rds)

  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

• @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. 

• 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,
  Dennis.

  • Edited by
    Dennis Mutsaers
    Saturday, January 25, 2020 11:29 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,
  Dennis.

  • Edited by
    Dennis Mutsaers
    Sunday, January 26, 2020 6:38 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

  Regards
  Fredrik

• Update..

  I installed the January 23, 2020—KB4534321 
  https://support.microsoft.com/en-us/help/4534321

  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

  Regards
  Fredrik

  • Edited by
    Fredrik_E
    Sunday, January 26, 2020 12:27 PM
    Spellings

• Hi Frederik,

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

  Best regards,
  Dennis.

• 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 ‘domainuser’ 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,
  Dennis.

  • Edited by
    Dennis Mutsaers
    Monday, January 27, 2020 8:15 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.

  Debuging

  1. There is SearchIndexer.exe process wich run as «NT AUTHORITYSYSTEM». 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.

  Issue

  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.

  Workaround

  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

• 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

  Then:

  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 appdataroaming 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.

  Regards

  Jeroen

• 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,3059 — The 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

• Scheduled task powershell.exe Restart-Service WSearch on Microsoft-Windows-Security-Auditing event ID 4647 is doing the trick for me.

• Do we have any «REAL» solution in sight here?  

• 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 appdataroaming 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.

  Regards

  Fredrik

• 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?

• 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.

  Regards

  Jeroen

• 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 onoff 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 solutionfixpatch..)

  Regards

  Fredrik

• @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%MicrosoftSearchDataApplications. Mount the VHDX File and you see nothing…

  Regards C-M

• @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:UsersXXXXXXAppDataRoamingMicrosoftSearchDataApplicationsS-1-5-21-689457963-1845298519-788813119-28645S-1-5-21-689457963-1845298519-788813119-28645.edb).
  (Time=0 seconds) «

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

  Regards

  Fredrik

• Hi Fredrik,i think so,

  under FSLogix GPO

  Administration TemplatesFSlogixEnable Search Roaming -> Disabled

  Administration TemplatesFSlogixEnable Search RoamingOffice 365 ContainersStore 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

• 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:UsersXXXXXXAppDataRoamingMicrosoftSearchDataApplications»User Sid»…

  Regards
  Fredrik

• 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

• 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 (..RoamingMicrosoftSearch..).
  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.

  Regards

  Fredrik

• ** 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?

  Dave

• 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?

• 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..)

  —-

  Triggers:

  On An Event

  Log: Application

  Source: Search-ProfileNotify

  Event ID: 2

  ——-
  Actions:

  powershell.exe 

  Restart-Service WSearch

• 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»

  C-M

• 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.

• 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

• 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?

• We have a microsoft open with this issue.

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

• We have a microsoft open with this issue.

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

  Hi,

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

  Thanks 

  Tobias

• 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 AppDataRoamingMicrosoftSearchDataApplications. 
  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.

• 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.

  Regards

  Jeroen

• 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 ?

  Thanks

• 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.
  https://virtualwarlock.net/how-to-install-the-fslogix-apps-agent/

• 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.

• 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:

  Hive	HKEY_LOCAL_MACHINE
  Key path	SOFTWAREMicrosoftWindows Search
  Value name	EnablePerUserCatalog
  Value type	REG_DWORD
  Value data	0x0 (0)

  Using Outlook to search:

  Hive	HKEY_CURRENT_USER
  Key path	SOFTWAREPoliciesMicrosoftoffice16.0outlooksearch
  Value name	defaultsearchscope
  Value type	REG_DWORD
  Value data	0x2 (2)

  Hive	HKEY_CURRENT_USER
  Key path	SOFTWAREPoliciesMicrosoftoffice16.0outlooksearch
  Value name	disabledownloadsearchprompt
  Value type	REG_DWORD
  Value data	0x1 (1)

  Hive	HKEY_CURRENT_USER
  Key path	SOFTWAREPoliciesMicrosoftoffice16.0outlooksearch
  Value name	SearchResultsCap
  Value type	REG_DWORD
  Value data	0x3E8 (1000)

  Hive	HKEY_CURRENT_USER
  Key path	SoftwareMicrosoftOffice16.0OutlookOptionsGeneral
  Value name	PONT_STRING
  Value type	REG_SZ
  Value data	53

• 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…

  ---

  https://www.nexsys.it/blog

  • Edited by
    frhell
    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

• Did you give it a test to see if FSLogix end up handling the searches 

• 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: 

  https://pastebin.com/9QptG8Mr

  Credits go to xplantefeve for
  providing the script. https://xplantefeve.io/posts/SchdTskOnEvent

  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.

• Anyone verified with latest Fslogix?

  https://t.co/NF82o0NDFL

• 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

  *sigh*

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