VMware Horizon Community
SchwarzC
Enthusiast
Enthusiast

Windows Search, Agent 2.14

This is more of a informational post, since the Update to 2.14 (from 2.13) we had problems with our Windows Search service (WSearch) (our config before: enabled, startup: automatic). At computer start-up the Windows Search was running but the startup type was set to disabled, this caused problems with Outlook 2016 and the live search was not working. We couldn`t figured out what caused the issue and no GPO or UEM LogIn Script you change this back.

After Investigation we figured out that in the the new agent (2.14) there are new (undocumented) changes and 2 new Registry Key where added.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CloudVolumes\WSearch

ServiceStartNeeded=1 (dword) - default 0

StartType=2 (dword) - default 0

These two are controlling the Windows Search and we have set them to the above for our config.

Best regards

30 Replies
R_Scheer
Contributor
Contributor

Hi szilagyic,

we have exactly the same problem. Do you already get an answer from the Vmware support?

Reply
0 Kudos
medvmwadm
Enthusiast
Enthusiast

Hi szilagyic,

we have exactly the same problem. Do you already get an answer from the Vmware support?

Not yet, I have had the case open for a couple of weeks, and so far no resolution yet.  In the meantime, what we did find that seems to work, is to go back to our AppStacks that were created with the 2.12 agent.  I have updated them with the 2.13 agent, and no problems (so far).  However VMware needs to provide a permanent solution as 2.15 is out now.  I will reply back once we have some results from support.

Reply
0 Kudos
mchadwick19
Hot Shot
Hot Shot

Any update on your case? We just ran into this as well.

We have one user whose search service fails to start and cannot be started administratively.

VDI Engineer VCP-DCV, VCP7-DTM, VCAP7-DTM Design
Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

Any update on your case? We just ran into this as well.

We have one user whose search service fails to start and cannot be started administratively.

Not yet.  The engineer thought the issue was with the Writable Volumes.  They had us push out a Writables update, but it did not fix the issue.  I have confirmed the issue is definitely with the AppStacks as was previously found here in this thread.  I'm supposed to have a followup call with VMware in the next couple of days to troubleshoot further.

Reply
0 Kudos
robsisk1972
Enthusiast
Enthusiast

I Have the same problem....Following!

Reply
0 Kudos
R_Scheer
Contributor
Contributor

We have upgraded to App Volumes 2.15. An update of the appstacks created in 2.14 did not solve the problem. We had to rebuild the appstacks under version 2.15. This also makes the Windows search work again. Meanwhile we have updated to version 2.16. Version 2.16 fixes further problems with Windows 10 that occurred during installation and execution of appstacks.

Reply
0 Kudos
robsisk1972
Enthusiast
Enthusiast

So I believe I finally have this working.   I worked with Tech support forever and we completely ditched modifying the UIA_Writable template.   Instead we made all of the changes to the .bat files in a App Volume and configured it to get mounted last.   However, This alone did not fix the issue.   The search service was still disabled at startup.    While waiting on a VMware to come up with another solution, I had another completely different issue that was know to be fixed by upgrading to 2.16.   The issue I'm speaking of was NOT in the Known Issues section of the 2.16 release notes.   Again, I had to call to find out that this was only in the internal release notes which is complete BS in my opinion.  So anyway, once I upgraded to 2.16, the default witeable_UIA disk with the Seach index app stack I created, just started to work as desired.    I am now, pushing these Oultook index files to the writeable and the windows search service had not failed to start yet and it has been 4 days with much testing.   

Hope this helps someone

Rob

Reply
0 Kudos
mchadwick19
Hot Shot
Hot Shot

Would you mind sharing your modifications to the .bat files?

VDI Engineer VCP-DCV, VCP7-DTM, VCAP7-DTM Design
Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

I had a case open for a while and they provided us with the fix to add this .bat file to the user's writables.  They suggested we push out a writable update from the AppVol Manager with this included.  We have not done this yet as we fixed the issue by using the 2.13 agent to re-create/update our AppStacks.  I was told also that 2.16 may fix this, but I have not confirmed yet.

The file name is "allvolattached.bat" and the contents is below:

sc.exe config wsearch start= demand

sc.exe start wsearch

You can either add this to the user's writable manually or push out as an update through the AppVol Manager.

The thought behind this is that when the writable is mounted, the last thing the agent does is run the .bat files and it will therefore run this and start the Windows Search service.  But,if the user doesn't have a writable, you'll still have an issue.

Reply
0 Kudos
robsisk1972
Enthusiast
Enthusiast

Here you go mchadwichk19. Still working good. Remember to set the App Stack to attach last.  Hope it helps

Reply
0 Kudos
Dempseyy93
Enthusiast
Enthusiast

Having encountered the same issue, we added a new line to the following bat file when creating a new template (AppVol v2.16.0.62):

Note: Add below command in new line...

Batch: startup_postsvc.bat

Command: sc config "wsearch" start=delayed-auto && sc start "wsearch"

This seems to bypass the disabled issue for us, however, we have had to update existing stacks by manually editing the service and moving users across to the new stack.

Cheers.

EDIT: This method works until the packaging vm reboots during provisioning. It will be disabled again, so im looking for a workaround in the event that an app needs a reboot mid package.

Reply
0 Kudos