After installing the AppVolumes agent and using UIA + Profile, we are unable to open the start menu (to open applications or anything), including search. AV 2.10 and View 6.2. Windows 10 on View w/o AppVolumes has no issues with start menu or search
I am experiencing the same problems with Horizon 7 and Windows 10.
Everything works with VMWare agent installed, however as soon as I install Horizon agent the start menu does not open. Going back to a snapshot is the only way to get the start button working again. This is preventing me from deploying Windows 10 images.
Hello,
for me everything is fine except if I use a writable. Which version of the agent are you using?
Cristiano
I've tried 7.0.0 and now 7.0.1 no luck.
Solved. It had something to do with my domain policies. Taking out of the OU fixed it. Weird that it does not effect the Windows 7 vm's.
Ken,
Windows 10 has different GOP's for Start Menu, even from Windows 8.x OS version. Check your policies for Start Menu and Desktop settings.
When I setup VDI environments for Clients, I suggest they place the VM's in a OU structure for VDI and not assign any policies. I also suggest to create a couple VDI UAT user accounts that don't have any policies and/or login scripts that will cause possible issues.
As you get the environment configured and running, then I start looking at their current GPO's and scripts to apply to the VDI OU structure. If your using UEM, this makes it much easier to manage.
A case was open for the same issue and VMware's response was stated below:
Hello Francesco,
My name is Peter Murphy, I am a Technical Support Supervisor in VMware.
We have been speaking with our engineering team and unfortunately there is no way for Windows 10 to work with dedicated linked clones when persistent disks are used.
I would like the opportunity to discuss this with you so please do let me know when you are available.
Kind regards,
Peter
Peter Murphy
Technical Support Supervisor | VMware Global Services Behan House, Ballincollig, Cork, Ireland
We had the same issue and adding exclude_path=\ProgramData\Microsoft\Windows\AppRepository to the snapvolumes.cfg file resolved this for us. Here is the original article
While working with a client I ran across this issue and spent some time drilling into the GPO's to find the offending policy. It wasn't limited to the default domain policy (albeit that's where we originally found the issue). Turns out that when we disabled the Audit Policy settings, UEM personalizations worked perfectly. Enabled, nothing worked that wasn't DirectFlex enabled.
In your policies, check:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy
Unfortunately I haven't had the time to run through the settings item by item yet, but it was our root cause without a doubt.
This worked for me. Had to edit the base image, take a new snapshot, and recompose.
To disable HotPlug capability using the vSphere Client:
devices.hotplug
and a value of false
.To disable HotPlug capability using the vSphere Web Client:
devices.hotplug
and a value of false
.In my testing this worked like a champ.
My environment is wholly unsupported but this is a step forward, much appreciated.
Now to see what the global impact of this change is going to be.
The issue is fixed in 2.13.1 but we just upgraded to 2.12 so had to use the workaround for now.
Thanks.
Unfortunately 2.13 introduces other issues related to writables so I had to roll back our agent to 2.12.1 until 2.13.3 comes out.
damned if you do; damned if you don't.
Appreciate the heads up though.
I also took the 1709 update so I'm just going through the motions now so i know how to test to make sure the things are fixed when they say they're supposed to be fixed.