VMware Horizon View provides different methods of provisioning and assigning users to virtual desktops. It is important to fully understand what benefits and limitations each method provides so that a solution can correctly be designed. The correct solution may encompass several desktop pools with a mixture of provisioning methods and user assignment.

If you are looking for a less technical explanation of Persistent vs Non Persistent desktops, please read the following article:

Persistent vs Non Persistent Virtual Desktops (Non Technical Explanation)

There are 2 desktop pool types available, ignoring the terminal services pool, which are; Automated pool and Manual pool.

• With an Automated pool, vCenter Server is used to create the virtual machines automatically from a master image. An automated pool will almost always be used in every deployment. View will then use vCenter to manage the VMs, such as power them on, delete them re-create them and so on as required.
• With a Manual pool, the desktop(s) already exist and could be a virtual machine both managed and unmanaged by vCenter or even a physical desktop. This pool type would not normally be used unless for a very specific reason as it would require another method to provision the desktops.

There are 2 user assignment options available; Dedicated and Floating.

• Dedicated user assignment is just that, a named user is assigned a specific desktop in the pool. No other users may use that desktop, even if the assigned user is not logged on and there are no spare desktops in the pool. Additionally with dedicated assignment users may be either assigned a desktop before they logon, or the first time the logon an unused desktop will be allocated to them to use from that point forward. (e.g DOMAIN\andy.barnes is assigned to desktop VDI-W8-123).
• Floating user assignment allows a user to logon to any desktop that is available within the desktop pool. Each time a user logs off and on, they will get a different randomly selected desktop each time.

(e.g. Logon 1 DOMAIN\andy.barnes assigned desktop VDI-W8-001

Logon 2 DOMAIN\andy.barnes assigned desktop VDI-W8-321)

There are 2 desktop provisioning methods available with View; Full Clones and Linked Clones (View Composer)

• Full Clone virtual machines utilise a master image in template format. The master image is built exactly as required, the template is the cloned by vCenter the required number of times to the exact same size as the virtual machine. So if the virtual machine is 25GB in size and you have 100 VMs that is 2.5TB. This of course requires a large amount of storage and to provision that many VMs may take quite some time. Once the desktops are created they are completely independent copies of the master image which must be managed and updated by another tool such as Altiris, WSUS, SCCM and various scripts as required.
• Linked clones utilize a feature called View Composer which decreases the storage space required and improves management. Linked clones utilise a master image in virtual machine format with at least one snapshot which represents the version instance of the master image you wish to create the desktops in the pool from. When a linked clone desktop pool is created, a replica VM (parent) is first provisioned, then the required number of desktops are created as a child VM of the replica VM. These linked clone desktops read from the replica disk and write changes to a diff disk. Initially before being powered on are KBs in size and during daily use can range from 1-5GB depending on OS, apps, pagefile and usage. However they represent around an 80% storage space saving on full clones. Furthermore with linked clones it is possible to configure the pool to refresh or delete the desktop at logoff, ensure the desktop is exactly as per the master image and discarding the diff disk changes that have occurred.

How to choose the correct type for the desktop pool?

While it is ideal to use an automated linked clone floating pool due to the benefits it provides, sometimes this may not always be the best for that specific user group.

Don’t think of a customer or solution as being only full clones or linked clones, understand the user groups which may be departmental and what applications they use. In most cases all users require a standard application stack such as Windows, Office, Adobe reader, flash etc.

However in addition to this, you may find a department which this standard stack suffices but a couple of users that also require MS Project and another 3rd party application. In this case rather than creating a separate pool just for this small requirement, ThinApp could be utilised to capture the application and make it available to those 2 users in the desktop pool. This saves having to clone the master image, install the 2 applications and manage 2 master images.

It would not be acceptable to decide to create the desktop pool as full clones because of a few requirements such as this. Doing so can have a dramatic affect on the underlying storage requirements and costs to the customer.

If you do have a scenario where an application cannot be ThinApp’d and a group of users must be able to for example install their own applications, this is a requirement for an automated full clone pool. However a desktop in this pool has a higher cost associated with it due to increased storage (e.g. 5GB to 25GB) and also increased management (e.g. solution required to update/manage desktop – Altiris, SCCM)

Example: Joe Bloggs Clothing Ltd (not making this an easy example)

Call center users (250 users) require Word, Outlook, CRM (web based)

Pool Type Suggested: Automated Linked Clone Floating pool

Why: 1.25TB storage instead of 6.25TB, Only require standard app stack, 1 master image to update for 250 users.

Finance Department User (10 users) require Office, Sales force, finance app, payroll app

Pool Type Suggested: Automated Linked Clone Floating pool

Why: 50GB storage instead of 250GB* without replica, Only require standard app stack plus some finance related applications. Cannot Thinapp Salesforce so create a master image for finance. Takes it to 2 master images to update for 260 users.

Finance Manager (2 users) require Office, Sales force, finance app, payroll app AND MS Project

Pool Type Suggested: Automated Linked Clone Floating pool

Why: Utilise the existing finance linked clone floating pool, and ThinApp MS Project and only make available for the 2 required users. Still 2 master images to update for 262 users. If a 3rd user needs MS Project then add them to the group to use it, still no change in required pools.

Engineering staff (100 users) require Office, Visio and Engineering client app

Pool Type Suggested: Automated Linked Clone Floating pool

Why: 500GB storage instead of 2.5TB, Only require standard app stack so keep with the original master image, Visio and engineering client app ThinApp’d. Still 2 master images to update for 362 users!

Developer (5 users) require Office, Visual studio, admin rights to test and to install any dev application

Pool Type Suggested: Automated full clone dedicated assignment

Why: These users must have their own desktop to install application in and test. It is not possible to ThinApp each test build and the developers are constantly installing new development tools. Requires a 3rd master image with the base development tools in. Updates are managed Altiris.

The end result here is 3 master images for 367 users in 5 distinct departments with different requirements, including a department with slightly different requirements for a small number of users. Operational management has been kept as simple as possible and large storage savings have been made by utilising linked clones and using ThinApp where possible.