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.
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
Hot or not? From the web to the motherboard to the training ground, get the scoop on what's in and...
Confidence in our power over machines also makes us guilty of hoping to bend reality to our code
Microsoft says its new Azure cloud database is all types of databases in one. Here's why that might be...
Edge computing will not replace cloud computing, though the two approaches can complement each other ...
The Rust-like open source language tackles application development where asynchrony leads to...
The popular code repository is trying to be a one-stop shop for developers to get more of their work...