nschlip's Posts

We are experiencing this same issue and opened a support case with VMWare. The conversation and responses are below, which I'm not too pleased about. We still have not gotten a resolution for this, but as of right now, no vMotion for UAG, I guess? VMWare Reply: "It is not recommended by VMware to vMotion an UAG and during a vMotion of UAG it is an expected behavior for the active connections to drop." My Reply: "Is there documentation you can provide or point me to, explaining that vMotion is not recommended for UAG without dropping connections?" VMWare Reply: "VMware QE team doesn’t test live vMotion of UAG so it is not officially supported (which is why we don’t see that in the official VMware UAG docs). VMware product documentation states what we DO support. If we had stated somewhere that vMotion can be used with UAG and it then failed to work, that would be a legitimate support case. UAG is a virtual appliance so automatic redeploy on a different host is the right way to have a UAG appliance in a different location."

I'm encountering this issue right now - I even upgraded composer and one of our connection servers to 7.13.1 (will upgrade the other connection server afterhours tonight) but I still can't change the gold image/snapshots on the affected pools. Did anyone ever find a resolution for this issue? This is a big deal - it worked in Horizon Administrator.....sigh.

We experienced the same issue when we moved from Horizon 7.4 agent to 7.5.1 - Persona wouldn't always sync, and some applications (such as Microsoft Outlook or Word) wouldn't launch 90% of the time, and the OS would crawl (Win7). We're now near half way into our Windows 10 1809 deployment, and continue to experience the same issue with persona, albeit worse. We've reached out to VMWare support and I was told that as of Windows 10 1709 VMWare stopped developing persona however, persona *should* work at least up to Windows 10 1803. We've also tried reaching out directly to our account team and continue to receive no response (near three weeks now). The same "solution" is repeated to us time and again - "have you tried UEM?" We would, except for the fact UEM is costly and we're on VMWare Advanced Licensing. Anyone have any other suggestions on how to manage user data in non-persisten VM's? Seems like since we paid to extend our support contract another year, that persona should work, and if it doesn't, be provided another solutaion that will at no additional cost (UEM).

Tossing in my two cents, we're experiencing the exact same issue. Windows 10 1809 w/View agent 7.8 - persona is highly inconsistent (and I do have local appdata disabled in the GPO, so it's not roaming; per another thrd, this was a suggested "fix", which did help some, but it's still not working well). To move to UEM is a cost issue, especially with how few VM's we run (on the desktop/client side, we have maybe 50-60 active sessions at most, at any given time - typically less).

Hello everyone, ***Note*** This is posted in another thread in the vmware communities as well, but thought I'd post to this one as well. I have an update to share on this - it may be fairly "wordy" (I know that's not a word), but here goes.... Issue Linked-clone Windows 10 VM's take a considerable amount of time (5-30 minutes, depending) to complete a guest OS restart cycle. Troubleshooting To make a long story short, I eventually noticed that disk IO was ZERO during a Windows 10 VM restart - it zero's out until the VM gets to the Windows 10 logo with the spinning circles, then the disk IO suddenly spikes once it gets to the login screen. From this, I began to look at disk configuration settings directly on the VM (vSphere -> right-click VM -> edit). I noticed the disk was using LSI SAS. I reviewed event logs, and noticed (on several Win10 VM's I tested with) there was a 10+ minute span of time with LSI_SAS event warnings. From there, I created a brand new Windows 10 master/gold VM using Paravirtual SCSI instead of LSI SAS. I then sanitized the mast VM and created a new pool - the Win10 linked-clone VM's are now down to 5 minute restarts. Much better, but still not great by any means. We then noticed that the .vmdk on the VM (all the linked-clone VM's, in fact) was using a "vmname.checkpoint.vmdk" - this "checkpoint" in the .vmdk indicates it's using a snapshot from the master VM. After many hours of testing, we found a sort of fix/workaround.... Fix If you: 1. Shut down the VM and migrate the storage (storage only) 2. Select configure per disk 3. Change the storage datastore for each disk on the VM, click Next, let it complete (may take anywhere from a few minutes to several, depending on disk size) 4. You should then have an alert on the VM indicating a consolidation is needed 5. Right-click the VM -> Snapshots -> Consolidate 6. Once the consolidation is finished, right click the VM - notice that you can now change the disk size (if needed) 7. Power up the VM, log in, and restart The restart time is now down to under 30 seconds (I've seen it as low as 7-8 seconds). I tested this using thick and thin disk provisioning, and either one didn't seem to make a difference. With 100% certainity (at least in my case) it has to do with the VM running off a "checkpoint.vmdk" disk - once the VM's disk is pointed back to its own self-named .vmdk, the restart issue is resolved. Now to provide some additional context to this: In vSphere, I create a new VM, set configuration options, point to an .iso, power up VM and proceed through our imaging process. Once this is complete, I log into the VM using a domain admin account, configure the OS, sanitize (prep it for cloning), and take a single snapshot. I then create (or edit) a View pool (for Win10 testing they have all been persisten/dedicated pool's) which provisioning VM's off the snap from that new gold VM. Something interesting during this composing process I noticed earlier today - when the linked-clone (we unfortunately do not have licensing for instant clones) is being provisioned, I noticed the disk being used is its own named "vmname.vmdk" - great! However, once provisioning is complete, the disk changes to "vmname.checkpoint.vmdk" Anyone have any insight into why that occurs? Why wouldn't the cloned VM just continue to use it own named .vmdk? Any helpful answer on that would be much appreciated! At any rate, we're able to fix/work around the Win10 restart slowness by, again, migrating the VM's storage only, to a new datastore, consolidate under snapshots, power up VM, and BAM - fixed. I hope all of this makes sense - if anyone is still experiencing Win10 restart slowness and is able to try this storage migration/consolidate process, please give it a try and let me know the result. So far it's been consisten for me, but I'd like to hear about what others experience is. This almost feels like a possible bug in vCenter or View somewhere, but I can't say for sure - anyone with VMWare have any thoughts to share? Also, fwiw, we're running a Pure storage array (not vSAN) with plenty of space available and excellent dedupe. Also, we're using EFI (though I've tried EFI and BIOS, neither seems to make a difference, as far as restart times are concerned). -Nathan

For AV we're running System Center Endpoint Protection - interesting on the interoperability matrix....when I select horizon 7.5.1 and Windows 10 agent, absoutely nothing comes up. Even if I select horizon 7.5.1 7.6 and 7.7, it displays nothing. Is that saying Win10 is not supported with any of those view agents?

Turned off Storage Accelerator on one of my Win10 test pools, and unfortunately that didn't seem to help - the VM is still at the Win10 circular dots going around in circles as I type this....going on 20 minutes now. Sigh.

So, in the vSphere console it shows the VM running tools 10338 - if I look directly on the VM in Windows in Apps & Features it shows tools 10.3.2.9925305. Comparing against the VMWare Product Interoperability Matrices, it doesn't have an option to select tools 10.3.2. However, it does show 10.3.5 as compatible with horizon 7.5.1, so I'll manually download that and give it a try.

We too are experiencing a similar issue - the gold (or master) Win10 1809 image works fine - I can reboot it and it completes the reboot in less than 30 seconds (about 26 seconds). However, any linked clones we create take upwards of 30 minutes for a reboot to complete! I've tried: - Linked clones using EFI - Linked clones using BIOS - Linked clones with EFI & Secure Boot The other interesting thing, is if I used vSphere to console to a linked clone VM where no one has logged into, and reboot the VM, it takes about 2min. 30 seconds - however, once someone logs into the VM and reboots, it takes anywhere from 15-30 minutes for the reboot to complete. It doesn't matter if it's using BIOS or EFI (secure boot is turned off for EFI). I have a support case open with VMWare to try and figure this out - if I find a solution I'll definitely let you know. EDIT: we're also running ESXi 6.7 U1 w/Horizon 7.5.1 (both composer and connection servers) w/latest VMWare tools from the hosts.

This right here - I deleted my persona profile, and logged into a VM running agent 7.6 and watched as my profile was created in our persona path however, nothing was under the folder - it didn't fully sync everything until I logged off, waited a few minutes, and logged back into the same VM - if I logged into a different VM (due to a refresh for example), then it was perform the same process and "break". If I logged into the same VM a second time, it seemed to work without issue. I then tried a third time logging into the same VM, and it broke again. Very odd issue, and it seems to work about 1 out of 5 times (just a guess, it's too random to be certain).

Hello everyone, We're experiencing this same issue - we tried with agent 7.5.1 and 7.6, with GPO applying roaming settings (which it does appear to be applying) however, when we log into a VM running one of these agents none of our Microsoft Office applications will launch. It's also extremely slow / sluggish. For the time being, we're reverting the agent to 7.4, but that's certainly not a long term solution. Has anyone heard from VMWare on this, and what they issue might be? Something else we discovered yesterday, is that the templates being used to apply these vmware GPO's is fairly outdated by at least a couple years, and is using an .adm template as opposed to .admx, so updating the policy may also help with this (we haven't tried it yet, but something we're looking into). Thanks, Nathan Horizon View 7.5 Gold image: Win 7 x64 enterprise