I deployed a Windows 10 1809 image, with no fancy software installed - just Office. VMware tools stops running after a few minutes, and only way to remedy this is to reboot the VM, however VMware tools stops again. The VM itself becomes non-responsive. This does not happen with the master image within the console. The issue starts after deployment.
Using an older version of Windows 10, previous build, VMware tools stays running just fine.
Yes, the power settings are set to high performance, so this is not an issue with hibernation.
I have tried various versions of VMware tools also - including the latest. Running the Horizon Agent 7.4.0. If I log into the master image at the VMware console prior to deployment, the VM runs fine with no issues. After de
Logs do not appear to display any information relevant to VMware tools stopping, and the event viewer on the VM itself does not display any errors either - Any suggestions?
In addition, enabling the Persona Management service locks up the machine - start menu won't appear, cannot open applications, file explorer windows, etc.
I also noticed this the other day, but in my master image. windows 10 v1809. I noticed that inside vSphere it said VMTools was not installed. When looking in the master, programs and applications shows vmware tools as an installed application however there are no services listed in services.msc, and no icon in the task bar by the clock. I have not yet figured out what is causing this issue either.
Did you use the VMware optimization tool?
I don't have a solution, but I'm posting to say I am experiencing the exact same problem with trying to deploy windows 10 1809 in our horizon view environment. I've opened a case up with support, about a month ago and they themselves seem to not be able to figure out the problem or reproduce it. I'm becoming ever so frustrated now because they seem to just give me "busy" work by "trying" different things, As i will mention below.
I have different pools that are of windows 1703, 1709, and 1803, enterprise version. Those pools have varying agents installed, 7.0 and 7.5.1. I run full desktops, persistent. I don't have this problem with them.
I am trying to deploy a pool that is composed of windows 1809 enterprise LTSC.
Vmware esxi 6.5 U1b on all hosts.
Vmware tools 10.3.10 and Agent 7.5.1 on image
I've run the optimizer and use the default VMware\Windows 10 template for optimization.
I normally follow https://www.ituda.com/vmware-horizon-view-windows-10-golden-image-creation/ for master image creation.
When I provision the pool with 30 desktops, (provision all dekstops upfront) they all customize and become available. But like you some of them become "agent unresponsive" after a few minutes as seen in the view console inventory. On virtual center the vm's in question, vmware tools is no longer running and the ip and dns name has disappeared in the summary. I open the console up for the vm and it is unresponsive. A reboot of the vm will restore things to normal, but like you the symptoms just described appear again after a few minutes. It's consistent but, it's random where the number of machines that become agent unresponsive vary between 10-20 each time i re-provision. In virtualcenter have 8 hosts in the vdi cluster and these bad vm's occur on all hosts. I can consistently repeat this process by deleting all the desktops and recreating 30 new ones, i use 30 different name for the vm's each time.
I have tried using installing different tools 10.1.3, 10.3.5 and different agents 7.6 on the master image, i still have the same problems.
I'm supposed to next create a new image from scratch. I'm getting tired of "trying" different things and not getting a proper root cause and a resolution for it.
The last time i spoke to a support person, they gave me this speech about how vmware tools even if it "crashes" the windows vm should still run fine and I should be able to connect to it. He was short of directly blaming the problem was with microsoft. At the end of all the reasons why it should not being happening that was said, i still didn't have a solution from support, Other than go create another image.
Yes I did run the optimization tool, i'll have to try and see if vmware tools runs fine before optimization.
Totally unrelated thread, but a thread with windows 1809 problems non the less.
Windows10-1809 boot time takes 5-6 minutes
I think i'm just going to throw in the towel on 1809 entirely. I really liked the idea of modern apps not being included in the 2019 LTSC (esenssially 1809), one less thing i have to worry about with that crap auto installing itself.
Doesn't look like vmware is going to throw much resources to help me on this one either...another round of collecting log data for a ticket open over a month. smh.
We are seeing the same issue on ESXi 6.0 Express Patch 19 with VMware Tools 10.3.5 and Horizon Agent 7.7.0. We've gone as far to build a generic Windows 10 1809 image from ISO with only VMware Tools and Horizon Agent installed.
Can anyone share their SR numbers so I can have our case linked and let our account team do some inquiries?
We came across Windows 10 1809 VDI may become "Agent Unreachable" state if the High Precision Event Timer (HPET) is.... We found that the "hpet0.present " parameter is already set to true on all of our parents.
We have the same issue with Horizon 7.5.1 and Windows 1809.
I checked the workaround from Vmware with this HPET Setting.
With this setting, the client stay available and doesn't turn to unreachable. But when I login to a client, it starts to flickering and client doesn't load the desktop and maybe other services.
This workaround is unusable for us.
I've exactly the same issue. The VDI are for a few minutes working, and then the hang. This occurs with unused VDI and also with VDIs in use. The HPET setting didn't solve the problem for me.
- Horizon 7.5.1
- vSphere 6.5.0 build 11925212
- Hybrid vSAN (not using storage accelerator)
- Windows 10 v1809 Enterprise x64 (latest patchlevel)
- latest VMware Tools (10.3.5x)
- using UEM 9.7 with mandatory profile
- no additional application installed
The master images (four from scratch) were created as described here: Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware
We don't have any problems with Windows 10 v1809 when using FullClones.
Does anyone have an SR open with VMware on this?
We had this VM lockup problem with W10 1809 as well, when we were running Horizon 7.4 (Connection Server and Agent). We tried many different combinations of Tools and newer Agents, and all of them continued to lock up several minutes after bootup until we upgraded the Connection Servers to 7.6. We have not seen one occurrence of the issue since we upgraded the servers to 7.6, with W10 1809 VMs running Agent 7.4 or 7.6.
I have no idea what caused this (or what component of CS could even cause this), but upgrading the Connection Servers to 7.6 was the definitive solution for us for this problem.
I'll test this out. We are still running connection server 7.4.0 with Horizon Agent 7.7.0 (This was done at the direction of support to resolve a bug).
So i went and tried and applied this to my pool. Windows 10 1809 VDI may become "Agent Unreachable" state if the High Precision Event Timer (HPET) is...https://kb.vmware.com/s/article/67175?lang=en_US
This was after a month of trying different things and the support rep specifically told me to try this today.
And surprisingly it has worked, all vm's provisioned and agents do NOT become unreachable.
This is on a windows 10 2019 LTSC image, based on a fresh install with only vmware tools 10.3.10 and agent 7.8. The View connection servers are 7.5.1
I added the line in adsi editor on a connection server (do it on one connection server it propagates to the others) below (see red arrow)
Looks promising, but I have to make a true golden image with the customization and software that i normally install. The pools I create are full desktops.
I did not experience the problems others mentioned after setting this to true. I'll post again once i create a new image and pool with the normal software and customization i apply.
Be careful, when you edit the Pool with the Horizon Admin, the entry is gone.
The only solution who helps us, was an update of the Horizon Environment from 7.5.1 to 7.8 (maybe 7.5.2 also works).
For my opinion, the problem is somewhere in the Horizon Version 7.5.1.
I was able to perform an upgrade of my Horizon environment from 7.5.1 to 7.5.2 . Hope this will fix the problem with Windows 10 v1809. I'll report the result by tomorrow.
The 7.5.2 release notes lists the problem as resolved:
When you say horizon admin, i'm not sure what you mean. Is that from the web browser admin interface? For this setting, i used ADSI edit.
I upgraded to 7.7 on one of my connection servers and that completely disabled the ability of tera 1 zero clients connecting. I haven't had the time to try 7.6, or 7.8 connection servers. But the work around to allowing tera1 clients to view connection servers have been working for me up to 7.5.1. So i'm stuck right now until we get money to replace the hundreds of tera1 zero clients.
Upgrading the Connection Server to 7.5.2 solve the problem with "agent unreachable" on Windows 10 v1809!
CS=7.5.1 with Horizon agent 7.5.2 = not working
CS=7.5.2 with Horizon agent 7.5.2 = working
You add the entry on ADSI, thats right.
I mean, when you edit the Pool and change something like "Max number of client", the entry on the ADSI DB for that pool is gone. The issue with the unavailable machine is back.