hkraaijeveld's Posts

I have seen this happen with the latest version of Adobe Acrobat DC. This installation is now Reader, Standard en Pro in one application. It appears that Adobe is trying to do something in the Windows start menu, which is not allowed by App Volumes: https://docs.vmware.com/en/VMware-App-Volumes/2212/app-volumes-admin-guide/GUID-0B37DF91-A0CB-4748-9A01-75C140D034D1.html That behaviour can be changed, but I have no idea what the effect would be. Still testing at a customer.

The update mechanism you found in the GUI is only for authorized OS updates within the same version. These hardly ever come out. As the manual says: Occasionally, VMware might authorize the update of one or more OS packages to rectify a critical vulnerability that affects a specific version of Unified Access Gateway and for which no viable workaround is available. The only way to update to a new version of the UAG is to export the current configuration, deploy a new version of the appliance and import the saved configuration.

The DNS entry is created by the Windows OS, since the default setting in Windows is to register itself with the DNS servers, as it should to make itself resolvable in the network infrastructure. Be aware, DNS is not and cannot be managed by VMware Horizon, so VMware Horizon cannot remove DNS entries. The IT- machine is a linked clone of the master VM, based on the master VM snapshot. This VM is used for the AD domain join and linked to a specific Instant Clone desktop pool. The instant-clone engine uses the master VM snapshot that you specified to create one internal template VM on the same datastore as the master VM. This internal template VM is linked to the master VM. The internal template VM is used to create the replica VMs. The system performs a domain join on this internal template VM, which ensures that all the proper Windows registry keys and settings are correctly populated. This process involves a reboot. Using this internal template VM for the domain-join process means that the process is performed only once on one VM. Without the internal template VM, the domain-join process would have to be performed on all the replica VMs that are created during the next step of the process.  If the IT VM no longer exists in your vCenter infrastructure, the DNS entries can obviously be removed and are probably part of a previous desktop pool rollout.  

Is there maybe a reason for the users wanting to be able to work this way? Have they been properly informed? Are there some persistence issues that make them do what they do? Is something not working the way it's supposed to for them? Do the functional requirements fit what has been built as to what it provides and how it's supposed to do it? Cloned vm's are usually meant to be short-lived and non-persistent, as to facilitate the fact they remain the same, granting a similar experience every time you log on to one randomly. It also saves you a ton of storage and can scale up and down very fast in terms of available desktops. It can be easily made highly available and redundant as well. Dedicated VM's can be managed differently, but cost more storage, but make persistence much easier. Recoverability changes a lot in this scenario as well, as does having desktops highly available, as this is usually a hard user to vm mapping. Honestly, I think you don't need to prove them something, you need to get them onboard for the right reasons.

This might answer a few of your findings: https://kb.vmware.com/s/article/50120424 Specifically: Note : Industry recommendations and only use .local for multicast DNS as stated in the RFC. .local is defined for a specific multicast use and not for general DNS. It is covered by https://tools.ietf.org/html/rfc6762 & MS recommendations https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/selecting-the-forest-root-domain (see caution section when selecting suffix). Cnames can be employed to allow alternate names if you have a .local server that you need to alias. And: As the UAG is an appliance based on photon o/s, never edit resolve.conf or the host file manually. Please update dns entries with redeployment or in the admin user interface - note any manual changes to the file will get over-ridden by admin user interface entries or by a reboot.

As you have noticed, Persona Management isn't a very popular choice for profile management as there is little to no information available about troubleshooting such issues. This has many reasons. If you want to get proper information about your case, I would suggest to contact VMware Support for this (GSS). Something you should also consider is the fact that VMware Horizon 6 does not support any Windows 10 release after 1709. Check this article for more information: Supported versions of Windows 10 on Horizon Agent Including All VDI Clones (Full Clones, Instant Clones, and Linked Clones on Horizon 7) (2149393) VMware Knowledge Base Windows 10 releases also have their lifecycle, depending on the version (pro, edu, enterprise). See this article for more information and specific EOL dates for all Windows 10 releases: https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet

Interesting. I have a similar situation at a customer which currently has a fresh installation of 2.16, a patched Windows 10 build 1607 LTSR and the same problem. After looking through all the patches Microsoft has done, there are 2 that strike me as possible candidates. In these a problem was identified with the MSI installer sometimes throwing an error as a known issue: https://support.microsoft.com/en-us/help/4487026/windows-10-update-kb4487026 Known issues in this update After installing this update, users may receive “Error 1309” while installing or uninstalling certain types of MSI and MSP files. Then the patch after this, the specifically found issue is fixed: https://support.microsoft.com/en-us/help/4489882/windows-10-update-kb4489882 Improvements and fixes Addresses an issue that may cause users to receive “Error 1309” while installing or uninstalling certain types of MSI and MSP files. So I am very curious as to what Microsoft "fixed" here, as it seems all these problems began at around this patch time. Problem is, all patches after this are cumulative. Does anyone know if it is possible to avoid installing this particular fix? There was a call logged with VMware, if any new information arises from this, I will post an update.

The APEX2800 card is a hardware solution from Teradici that helps the pcoip_server_win32.exe process to encode the stream and thus reduce stress on cpu and memory. It does introduce a very tiny bit of latency, since the desktop protocol is sent through the card and then to the endpoint, instead of directly. The fact that you actually notice that lag is very dependant on the usecase. In some cases you notice nothing, in others you might annoy some endusers. Nvidia GRID is a solution that enables the VM's to use graphical acceleration by granting them access to the Nvidia GRID hardware trough use of a software layer, and giving the VM an actual graphics card in the device manager. New versions of the hardware actually assist the remoting protocol (Blast Extreme) with H.264 encoding, thus reducing latency instead of adding. This is dependant on your hardware and level of GRID software version. A game is a very poor test for a VDI solution to be honest, especially since the behaviour of your applications can differ, even in the same session. Real world testing of your actual usecase is a better way to take a look at performance.