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
FPSRoland
Contributor
Contributor

Hello,

We have the same issue and we tried your solution but it does not work.

After modifying the registry keys and restarting the service, the values of both keys are reset to 0. :smileycry:

How do you set the value on the reg keys ? In the master image or GPO,…?

0 Kudos
SchwarzC
Enthusiast
Enthusiast

Hi FPSRoland​,

we implemented it as a Computer GPO - we did not touch the Golden Image:

ActionUpdate

Properties

HiveHKEY_LOCAL_MACHINE
Key pathSOFTWARE\CloudVolumes\WSearch
Value nameStartType
Value typeREG_DWORD
Value data0x2 (2)

ActionUpdate

Properties

HiveHKEY_LOCAL_MACHINE
Key pathSOFTWARE\CloudVolumes\WSearch
Value nameServiceStartNeeded
Value typeREG_DWORD
Value data0x1 (1)

Best regards

0 Kudos
FPSRoland
Contributor
Contributor

Which version of Windows do you have?
(we have Window 10 LTSB)

0 Kudos
SchwarzC
Enthusiast
Enthusiast

1703 Windows 10 64bit non LTSB

VDINinja311
Enthusiast
Enthusiast

SchwarzC

Thank you for this post! We upgraded from 2.13.2 to 2.14.2 just last week and found this issue today.

Just now getting around to testing out the Computer GPO like you posted.

0 Kudos
VDINinja311
Enthusiast
Enthusiast

SchwarzC

After setting a GPO to set these keys and it didn't fix the issue like yours did, we did some more troubleshooting and figured out this issue doesn't exist when any appstacks are attached to the user. We logged into the same linked clone desktops with the same AV 2.14.2 agent with no AppStacks attached and this is no longer an issue. The Windows Search service isn't disabled and no issues with the search indexer appear. We are going to determine if all of them are doing this, or if just one AppStack is. More to follow.

0 Kudos
maharajan_be
Enthusiast
Enthusiast

We had the same issue. After setting the "Windows Search" service to manual on Golden Image, Outlook search started working. OS: Win10 LTSB, Outlook 2013, App volume 2.14

0 Kudos
VDINinja311
Enthusiast
Enthusiast

maharajan.be

No other changes were needed? Just simply changing to Manual on Master Image did it?

0 Kudos
mana1
Contributor
Contributor

Yep, I didn't make any other changes other than setting "Windows Search" service to manual on Golden/Master image.

0 Kudos
VDINinja311
Enthusiast
Enthusiast

In our environment we believe the upgrade of the 2.13.2 to 2.14.2 agent on our Capture and Build VM (which we do all of our provisioning on) has made every AppStack update after the agent upgrade change the Windows Search service to disabled inside the AppStack, which has been causing our issues. We believe this is due to the new HKLM\Software\CloudVolumes\WSearch hive keys which upon the AV Agent starting on the Capture and Build VM is setting the Windows Search service to disabled, and provisioning is capturing that as a change.

We can update an AppStack that was previously updated using the 2.13.2 AV Agent and the Windows Search service is set to Automatic (Delayed Start) after it has been attached to a machine, but any AppStack that we update with the 2.14.2 AV Agent, the Windows Search service is set to Disabled after it has been attached to a machine.

Our workaround right now is to update the AppStack and in provisioning change the Windows Search service to Automatic (Delayed Start)

Anyone else experiencing this?

0 Kudos
bjartest
Enthusiast
Enthusiast

We seem to be experiencing the same issues. We are running Windows 10 Enterprise 2016 LTSB with appvol agent 2.14.2. We have Office 2016 in base image and running instant clones. Roaming the ost file with UEM. With no appstacks attached Windows Search is set to Automatic (Delayed Start). If we attach appstacks made with 2.14.0 it gets disabled (but says running if I check under services). Problem is it doesnt add outlook to the indexer so it more or less breaks it. Attaching appstack made with 2.13 Windows Search is set to Automatic (Delayed Start). Outlook gets added to the indexer on startup but then I get the windows installer reconfigure on each outlook startup. If I recreate the indexer database outlook starts without reconfigure phase and indexing works.

0 Kudos
VDINinja311
Enthusiast
Enthusiast

Update to our situation. We contacted VMware support and they confirmed that they have seen our issues before and to rebuild every appstack using the 2.14.2 template. So for right now as a workaround we are manually setting the Windows Search service to Automatic (Delayed Start) during provisioning. Unless we rebuild every appstack with 2.14.2, which is 40+ appstacks.

0 Kudos
szilagyic
Hot Shot
Hot Shot

We just discovered this issue today.  So, was VMware telling you to go through and update your AppStacks, or do you have to rebuild each one from scratch?  I just went through ours, as re-saving them fixed some other problems we were having with 2.14.  I noticed that when I go to update any of our AppStacks, it disables the Windows Search service on the provisioning VM I'm using.

I have been trying the GPO mentioned in this thread to push out those two registry keys to our VMs in the pools as well as the VMs we use to provision the AppStacks with.  We do not want Windows Search disabled here at all, as our users heavily rely on it and it's causing a bunch of problems when the service is not running.

On the VM we use to provision the AppStacks, the registry values are being pushed to it just fine and the Windows Search service is running, but when I try to update an existing AppStack on it, the "preparing to provision... please wait" box comes up and stays there, and the process does not continue.  If I restart the AppVol service on this VM, it changes the values of the registry back to zero.  So far I'm stuck and cannot seem to get our provisioning VM working in order to update the AppStacks, if that is truly the fix?

Thanks for your help.

0 Kudos
VDINinja311
Enthusiast
Enthusiast

szilagyic

We found out that downgrading the AV Agent on the provisioning (capture and build) machine back down to 2.13.2 was also a workaround for this issue until we could rebuild all our appstacks with the 2.14.2 template. We have been running like this since we haven't rebuilt all of our appstacks with the 2.14.2 template yet.

0 Kudos
szilagyic
Hot Shot
Hot Shot

We found out that downgrading the AV Agent on the provisioning (capture and build) machine back down to 2.13.2 was also a workaround for this issue until we could rebuild all our appstacks with the 2.14.2 template. We have been running like this since we haven't rebuilt all of our appstacks with the 2.14.2 template yet.

OK thank you for the info.  Just curious, what version of the AppVol Manager do you use then?  I did not know  you could use a different agent version than the manager, i thought they always had to be the same.

I have gone through and updated our AppStacks using the 2.14 agent on our provisioning VM, and I'm still seeing the issue.  When you say rebuild, are you having to update your AppStacks, or re-install all of your applications from scratch?

0 Kudos
VDINinja311
Enthusiast
Enthusiast

The permanent fix was to rebuild the Appstacks with a AppVolumes template that was created fresh from 2.14.2.

Support said there wasn't going to be an issue having the 2.13.2 agent on the provisioning VM.

We are on 2.14.2 on both agent and manager sides. Only the provisioning VM is on 2.13.2 to workaround this issue.

0 Kudos
szilagyic
Hot Shot
Hot Shot

The permanent fix was to rebuild the Appstacks with a AppVolumes template that was created fresh from 2.14.2.

Support said there wasn't going to be an issue having the 2.13.2 agent on the provisioning VM.

We are on 2.14.2 on both agent and manager sides. Only the provisioning VM is on 2.13.2 to workaround this issue.

Ahh, OK.  I am doing the same thing now, too, and so far so good as I'm now able to update each AppStack and in each one, I'm enabling Windows Search again.  Unfortunately that means we are going to have to go through all of our AppStacks and do this.  Ugghh.

0 Kudos
szilagyic
Hot Shot
Hot Shot

The permanent fix was to rebuild the Appstacks with a AppVolumes template that was created fresh from 2.14.2.

Support said there wasn't going to be an issue having the 2.13.2 agent on the provisioning VM.

We are on 2.14.2 on both agent and manager sides. Only the provisioning VM is on 2.13.2 to workaround this issue.

Ahh, OK.  I am doing the same thing now, too, and so far so good as I'm now able to update each AppStack and in each one, I'm enabling Windows Search again.  Unfortunately that means we are going to have to go through all of our AppStacks and do this.  Ugghh.

So far I have not had any luck using a capturing/provisioning VM with the older 2.13 agent and fixing our AppStacks.  I've re-enabled the Windows Search service in it, but somehow the service is still being disabled on the VMs that we push the AppStacks to.

I did another test by using the new template and that does fix the issue like you said.  I'm not sure how we are going to proceed here, as we have a ton of AppStacks that would be great if we could fix, but so far no luck

0 Kudos
szilagyic
Hot Shot
Hot Shot

I'm opening a case here on this, as this morning we discovered we are still having the issue of the Windows Search service being stopped or disabled on some (but not all) of our user's VMs.  This is after I have re-created AppStacks based on the new 2.14 template.  I have tried all suggestions in this thread, having sporadic users fixed but others not.  There is no consistency with the issues, so I'm hoping VMware can direct a better fix.  This is crazy that we should have to re-create or modify AppStacks that were previously created.

0 Kudos