Writable Volumes Search indexing

[jg27]

We're having an issue with search indexing with Writable Volumes.  At the very least it's making OST files unsearchable within outlook.  We're currently using the uia_plus_profile and leaving the search and outlook OST paths as default.  After longing into a different/recomposed VM, the search service fails to start with 'The windows search service has failed to remove the old search index. internal error <0,0x80070005>." and will never work again.  About 70% of my test users are not experiencing the problem, but the rest are.  The indexing for outlook is stored in Programdata\Microsoft\Search.  and doesn't have any data in it(or it's getting erased on login).   I came across this article VMware Knowledge Base , but it references not needed to apply the setting in 2.14 and i assume that the setting carried on until 2.16.   Has anyone ran into this problem?  below are the system details.  Any suggestions are appreciated.

AppVolumes 2.16

Writable Profile: uia_plus_profile

windows 10 1809

View Agent 7.8

Linked Clones

UEM 2.16

[cbaptiste · Accepted solution]

I also ran to this issue. VMware support were not much help. At the end it was concluded that the experience is flawed so I stopped using writable volumes. The headache that comes with them is unbearable. If you want a suitable solution that works, I hear great things about FSLogix. They are leading when it comes to deploying Outlook cache mode on non-persistent desktops with Windows search index. Apparently "it just works."

P.S I do not know for certain since I have not had a chance to deploy it in my environment yet. But I will start looking at it soon.

[SummaCollege]

We are seeing the same error using the latest AppVolumes. Search is not starting and exiting with the same error. Testing different profiles (UIA, ProfileOnly) showed the same error. Also the error is not consistent, not all users experience this.

Anyone has more info on this??