VMware's VDI solution makes virtual desktops real, but not particularly easy to manage
Everyone in the pool
Once the core components of View are installed and running, at least one desktop pool needs to be built to support the users. The primary source of the desktop pool is a single VM that's built like any other Windows VM. The base OS is installed, then patches and service packs, followed by applications, and so forth until the VM is completely prepped and ready for a user. This source VM is then joined to the domain, and the VMware Agent is installed. The Agent is a small piece of code that runs on every View desktop and permits interaction with the View server.
Additionally, all the Microsoft Sysprep code must be installed on the vCenter Server to facilitate the automatic building of new desktops from the single image. This is the code that permits Windows machines to be cloned and run on the same network as unique entities, with various unique parameters such as the SID (security identifier) modified during the cloning process.
Once all those pieces are in place, the source VM is shut down, and a snapshot is taken of the system. This snapshot forms the basis of all subsequent desktop VMs.
Back in the VMware View Web interface, a desktop pool can now be created. Desktop pools can be built in several ways. The most common is likely to be linked clones. This method is used by View to allow for a large number of desktops without requiring that each desktop have a separate base disk image. Even a small desktop VM might require a 10GB disk, and creating a pool with 100 desktops would then require 1TB in storage. However, using linked clones, the total storage requirements of 100 users will only require a fraction of that space. View manages this trick by using the snapshot of the source VM as a baseline and creating links to that baseline for each VM. Thus, each desktop runs as an extension to the primary, with any and all changes made to the VM during normal use stored as a delta to the original. Also, View offers the option of creating a user disk with a fixed limit for users to store files separately from the linked clone.
In production, you'll want to use Microsoft Active Directory Group Policy to limit or prevent users from storing anything locally to the VM or to the user disk by redirecting My Documents and other directories to file shares served elsewhere. This is very similar to a normal Microsoft Terminal Services or Citrix installation.
The pool of desktop VMs can also be created with support for persistent or non-persistent desktop sessions. The difference here is whether or not a user is tied to a specific desktop instance, or if they simply log in to the next available desktop. In a call-center scenario, non-persistent desktops are probably the best idea, since users likely won't be using more than one or two applications, nor will they need a place to park their personal files.
Otherwise, persistent desktops are likely to be the best bet. This assigns a specific desktop to a specific user during their initial log-in, and they will always be connected to that desktop for each subsequent log-in, much like they would with a physical desktop beneath their desk.
You may still be better off sticking with Win7 or Win8.1, given the wide range of ongoing Win10...
With myriad problems now evident, it may be best to skip the Anniversary Update for now
An unlikely combination of two Windows updates can reduce scan times from hours to minutes
These 13 tools and techniques prove that, when it comes to coding, laziness is a virtue
GitLab and Atlassian have GitHub in the cross-hairs among organizations seeking enterprise-grade...
Concurrency and runtime improvements make the JVM language attractive for IoT development
When a core team member bows out, a crucial process hits an insurmountable obstacle -- until IT figures...