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.

Regardless of the parameters, creating the desktop pool is accomplished the same way: via a JavaScript-based wizard delivered from the View Web interface. It's not pretty, but it gets the job done. There are some caveats to be mentioned, such as the inability for a desktop pool to be properly created if the source VM maps to a floppy or CD-ROM ISO image. In fact, pool creation will fail if this is the case, with seemingly nonsensical "File not found" error messages. Only by changing the mappings to "Client Device" will the pool build as it should. This is decidedly non-obvious and became a very annoying issue in my deployment. Judging by the number of questions asked about this problem on VMware's forums, this is a relatively minor problem and easy to fix, yet is largely unknown and poorly documented. As with VMware's ESX and vCenter products, the error messages and logging in View could be greatly improved to alleviate such problems.

Following the creation of a linked clone pool, View uses the snapshot taken of the source VM to devise a baseline desktop instance, and then builds the remainder of the desktop pool from that image. Each desktop is assigned a name derived from the baseline name given in the setup wizard, followed by an incrementing number. Each Windows desktop is also Sysprepped and readied for log-in. The time required to construct this farm varies greatly, depending on the number of desktops produced, the speed of the VMware ESX host, and the speed of the storage behind the host. Once generated, the pool is visible in the VMware ViewAdministrator, and security settings can be assigned.