BenFB's Accepted Solutions

While linked clones are associated with a parent/snapshot they are dependent on a replica which is as a clone of the parent at a specific snapshot. Technically you can delete snapshots or the entire parent and everything should continue to function so long as the replica is preserved. Reverting a snapshot just changes the current state of the parent (discarding any changes made since that snapshot was taken). The snapshot is not removed and it will not impact the linked clones.

You have a number of options here. MFA/2-factor authentication can be enforced natively on the UAG or connection servers. There are also third-party alternatives. MFA on all connection server(s) or UAG (Typically to enforce it for all remote access. MFA should be a requirement for external access and many regulations that apply to businesses require it). Most MFA solutions allow you to define policies by user/group. This could allow MFA to be enforced for some AD groups/entitlements while others are bypassed. If you aren't able to define policies you could configure MFA on a separate load balanced VIP and connection server(s). You can then tag the connections servers and pools so they are only accessible from that specific VIP. This will ensure users that need access to certain pools must perform MFA but on a shared endpoint users will have to know which VIP to pick. There are alternatives like F5 APM which replace the UAG and allow for a more selective enforcement of policies.

Our VMware team has been consistent in stating the Horizon desktop license can be used for virtual desktops and all infrastructure that support the environment (e.g. PSC/VCSA, UAG, AD, file server, AppVolumes, UEM, etc...). It's a gray area if that file server is also supporting other servers or desktops. Always check with your VMware account team and internal legal to verify you are in compliance. Depending on your use case you might be able to just get a written exception from VMware.

First always make sure that the SQL versions you want to run are supported (VMware Product Interoperability Matrices). You should then be able to do the following. Stop App Volumes services Backup the SQL database on the original Restore the SQL database to the new server Reconfigure the ODBC connection Configure a SQL Server ODBC Connection​ Start App Volumes services Test and validate functionality

I would recommend contacting your VMware team and get something in writing on what's allowed if you must do it this way. To keep things simple and due to the nature of the workloads we run seperate vCenter for desktops and servers. Even the supporting Horizon infrastructure is run in the server environment.

I believe you need a active support contract to be able to upgrade the license. Just an FYI, Horizon 6.x goes end of general support on 2019/06/19. https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf

A fresh install is always preferred but upgrades are supported. You need to uninstall the Horizon components before the OS upgrade. Upgrade Requirements for Windows 10 Operating Systems (2148176) Installation order of End User Computing Agents for User Environment Manager (UEM) and App Volumes (2118048)

Horizon View 5.x went end of general support on 2016/09/14 and 5.1.3 was technically not supported long before that (support applies to the latest maintenance release). Horizon View 6.x is going end of support on 2019/06/19. You need to prioritize an upgrade to the latest Horizon 7.x release. Given your situation I would advise a greenfield deployment and migration. Server 2019 support for RDS was only just added in 7.7.0. https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf Release Notes for VMware Horizon 7 version 7.7

Full clones can be safely storage vMotion. Configuring the vSphere Environment for View Composer Use vSphere DRS. DRS efficiently distributes linked-clone virtual machines among your hosts. Note: Storage vMotion is not supported for linked-clone desktops. Migrate Linked-Clone Virtual Machines to Another Datastore Note: Do not use vSphere Client or vCenter Server to migrate or manage linked-clone virtual machines. Do not use Storage vMotion to migrate linked-clone virtual machines to other datastores.

RADIUS is completed on the UAG. Once successful the AD credentials are forwarded from the UAG to the connection server which authenticates the user against AD. If successful and enabled the credentials are then passed to the virtual desktop to log the user in.

Storage DRS is not supported and must be disabled for linked clones. It's fully supported for instant-clones, full clones and vCenter source VMs. Instant-Clone Desktop Pools Worksheet for Creating an Instant-Clone Desktop Pool in Horizon Console Worksheet for Creating an Automated Pool That Contains Full Virtual Machines in Horizon Console

I would not recommend running mixed connection servers versions within a pod. It's only supported to run different versions in different pods with Cloud Pod Architecture (CPA) (e.g. Pod1 has two connection servers running 7.4.0 and Pod2 has two connection servers running 7.6.0). For what it's worth I'm currently running UAG 3.3.1 using only Blast with Horizon 7.4.0 without issue. I would do the following. Add your additional connection server(s) running 7.4.0 and point the UAG to those (3.3.1 should work but if you need to be strict on compatibility deploy 3.3.0 and then once you upgrade to 7.6.0 upgrade the UAG). Decomission the security servers/connection servers. Upgrade the new connection server(s) from 7.4.0 to 7.6.0. Horizon 7 Upgrade Overview Important: After you upgrade a Connection Server instance to the latest version, you cannot downgrade that instance to an earlier version. After you upgrade all Connection Server instances in a replicated group, you cannot add another instance that runs an earlier version. Upgrade Connection Servers in a Replicated Group Important: If you do not upgrade all Connection Server instances in a replicated group, the health indicators in the Horizon Administrator dashboard might show that one or more instances are in an error state. This situation arises because different versions supply different kinds of data. The solution is to upgrade all instances in the replicated group.

I would expect that you could upgrade from 7.3.1 directly to 7.3.6. However, given the upgrade path that you linked and how simple it is I would first upgrade to 7.3.2 and then upgrade to 7.6.0. Horizon 7 Upgrades Just make sure that the versions of vCenter, ESXi, VMware Tools, UAG/Access Point, Horizon Client or zero/thin clients that you may be running are supported with Horizon 7.6.0. You will also want to check with any other VMware or third-party solutions that integrate with the environment.

If you truly need 100% availability then Cloud Pod Architecture (CPA) would be the way to do this. However, that would require building out additional connection servers which may not be ideal for your short term use case. If ongoing you need to provide 100% availability then you should look at using CPA but it will require double the amount of hosts. For your use case what you have laid out should work with one exception. You can not reconfigure the pools from the 6.0 to 6.5 vCenter (There is also no way to migrate a linked clone from one vCenter to another). You would need to build new parallel pools on 6.5, add the existing entitlements to the new pool and then remove the entitlement from the old pool. The users would then get new desktops on their next login. Once all users have been migrated you can delete the old pools, unregister the 6.0 vCenter and rebuild the 6.0 hosts with 6.5. Any reason you are looking at 6.5 instead of 6.7 U1? 6.7 U1 has a number of new features focused on VDI (vMotion for NVIDIA vGPU, Virtual TPM, Microsoft Virtualization Based Security).

If the pool contains a single VM it will always be powered on even if the Remote Machine Power Policy is set to "Take no power action". Power Policies for Desktop Pools Note: When you add a machine to a manual pool, Horizon 7 powers on the machine to ensure that it is fully configured, even when you select the Power off or Take no power action power policy. After Horizon Agent is configured, it is marked as Ready, and the normal power-management settings for the pool apply. For manual pools with machines that are managed by vCenter Server, Horizon 7 ensures that a spare machine is powered on so that users can connect to it. The spare machine is powered on no matter which power policy is in effect.

This has plagued us for years and the best solution has been to increase the hard disk. You could look at quotas for the users profile but I would not recommend it anywhere else. For our full VMs we've just been increasing the hard disk for growth. With linked/instant clones you can increase the hard disk and then must recompose the pool.