Linked clone desktops with persistent disks on Win 10 build 1607
In the same pool - After a recompose, the search menu does not work on some machines and on others it works.
If the master image is the same for all the machines, why would the results be different?
On one machine, a second recompose fixed the issue, but on others, nothing works.
We are on Horizon 7.0.2 - 4356666
Check the Windows Search service. It most likely is not started. We ran into similar issues a lot previously when we used Unidesk on top of Horizon. Haven't had any issue since using Linked Clones though. I will check my notes when I am back in office in case there is anything we documented earlier.
Did this ever get fixed or anyone have any idea on this one?
We are running into what seems like the same issue, but we haven't been able to determine if a recompose fixes it or not. Only seems to happen to specific users (that we know of) and not every day. We are also on Win10 1607 build, floating pool of non-persistent linked clones. No persistent disks. Using UEM and AppVolumes. Horizon 7.0.2.
Symptoms: Windows search will not open as well as Calculator (modern app) will not open.
Windows Search service is disabled on our master image, and search works for 99% of our users. When looking at the Windows Search service when a user is logged in, its set back to Automatic (Delayed Start) and is running. Wonder if Quikprep is doing that?
Going to attempt to test what having Windows Search set to Automatic (Delayed Start) on the Master Image. Assuming the service was disabled because we ran the VMWare OS Optimization tool when creating the Master Image.
Had the same issues on few machines post recompose. The only workaround i have is to reset the windows OS profile for the user to get it working. Got to know that this is happening on some of the physical laptops as well. Not sure about the exact cause.
I have narrowed this issue down to SearchUI.exe isn't running (And won't run manually). This is the Cortana process. Looks like this runs the Search UI (So Search won't open when doing a Windows Key + S or clicking the Search on the taskbar/start menu)
This is from C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\SearchUI.exe
Attempting to find out what is causing it to not run. I put a VM that had this issue into Maintenance Mode and logged in with a local admin account via vSphere console and even under that profile the exe wouldn't run.
Looks like having Windows Search service and Windows Firewall service set to disabled on our Master Image might have been causing this. VMware OSOT disabled the Windows Search service back when we made the Image, but I believe at one point we set the Windows Firewall service to disabled ourselves.
We never caught it until now because with any App Volumes AppStacks attached both the Windows Firewall service and Search service are both running. I was only able to get my Search/Calculator to break when logging into a very basic test user account that has no AppStacks attached. (All of our end users at least have our Core Applications attached at logon). Now I am wondering if when we are provisioning AppStacks on our special Capture and Build machine if it is capturing it's services and both are running at the time of provisioning...
Only thing I've found that fixes this is to delete the usrclass.dat file from D:\Users\%username%\AppData\Local\Microsoft\Windows\.
I think this file manages something to do with the metro apps...but we don't use any of those at my org so it doesn't hurt us at all. I'd try deleting that file if you do a recompose and your start menu is broken. Also - as was mentioned above, you have to have Windows Firewall enabled.
I've written a PS script to reboot the computer and then delete all the usrclass.dat files from that location ever day...only thing we might run into is if we do a recompose in the middle of the day no one's start menu will work. 😕