Deploying Windows virtual desktop pools lets you have more control over what's delivered to users, but they require...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
With virtual desktop pools, Windows administrators manage a collection of identically configured virtual desktops so that all users who connect to a particular virtual machine (VM) get an identical desktop: same operating system, same installed applications, same features enabled or disabled. Admins can make them available to collections of end users according to job function, physical location, remote office versus in-office, or by any other logical grouping of requirements.
Pooling virtual desktops also allows users to connect to their pools from most anywhere in an IT infrastructure; they can wander around their company or the world, never having to wonder if they'll have the appropriate desktop and applications available when they log in to their corporate network.
Follow these best practices for creating, deploying and managing Windows virtual desktop pools.
Test the waters: Planning virtual desktop pools
In your IT environment, you probably already have a collection of specific OS images for various groups of users based on their needs for applications or features. You should use those images as the basis for virtual desktop pool planning.
For example, you might plan pools for everyone in Accounting or Sales. If you already classify users in Active Directory by job function, application requirements or physical location, that's another logical place to start looking at common attributes and requirements for virtual desktop users.
Once you identify your applications and features for each pool, you need to build an image and test it. Your next step should be a limited beta test for each virtual desktop pool image and its applications within a select group of technically savvy end users who can put the virtual desktop through a serious workout.
As you test Windows virtual desktop pools, consider the following:
- Where is user data stored?
- Is user data backed up, and who's responsible for those backups?
- What IT standards will be enforced? (For example, you may need to display logon security pop-up messages.)
- How will OS and application updates be handled for virtual desktop pool images?
- Will you lock users out of accessing a local physical desktop once they are assigned to a pool?
Dive in: Deploying virtual desktop pools
More on virtual desktop pools
Managing VMware View linked clones pools
Publishing View virtual desktop pools
Chapter excerpt: How to publish floating View desktop pools
Now that your pool images have been built and tested, it's time to start rolling out your virtual desktop pools. A phased-in approach is preferable when migrating end users from physical desktops to a virtual desktop environment. Be sure to follow your organization's change management processes and always have a back-out plan if deployment and end-user adoption does not go as planned.
First, you must create and assign an image to each virtual desktop pool. This process is similar to deploying VMs on a Hyper-V server but with considerably more options, including configuration of user resources, user storage assignments and error handling. Review these options closely because they will have a direct effect on the end-user experience.
There are also a slew of server-side settings that must be provided while deploying Windows virtual desktop pools across your servers. There are some similarities between Windows Server 2008 R2 and Windows Server 2012, but you should review Windows server instructions for configuring virtual desktop pool support on each platform.
Virtual desktop pools can be deployed and supported across multiple back-end servers. Multiple pools can also reside on the same back-end server. For extra credit points, you can even run your pools on clustered Windows servers for mission-critical desktops.
Stay out of the deep end: Rules of the pools
There are a few other guidelines for deploying and managing Windows virtual desktop pools. First, you need at least two virtual machines to create a pool. Without at least two VMs, you have more of a puddle than a pool.
To configure your virtual desktop pools on a back-end server, you must have local administrator privileges on that server. You can acquire local admin rights by adding your logon to the Local Administrators group on the server or by being a member of another local or domaingroup that has been granted local admin rights.
A virtual desktop can only belong to one pool. Also, all VMs within a virtual desktop pool must be identical -- that is, they must use the same OS image with the same applications installed and the same features enabled or disabled.
If a user logs off from a virtual desktop in a pool, any unsaved work might be lost. If a user disconnects from their desktop, the next time they connect to it their desktop and applications will be in the same state as when they disconnected. With Windows Server 2012, you have the option of rolling back to the initial virtual desktop state or leaving the desktop as it was when the user last logged off.
Typically, all back-end Windows servers that support virtual desktop pools must belong to the same domain.
Scalability considerations come into play when working with large numbers of VMs or Windows virtual desktop pools. Consult your Windows server documentation for more information on scaling back-end servers for desktop pooling.
About the authors
Ed Tittel is a 30-plus-year IT veteran who's worked as a software developer, networking consultant, technical trainer, writer and expert witness. Perhaps best known for creating the Exam Cram series in the late 1990s, Ed has contributed to books on computing topics. Earl Follis has been working in IT for over 25 years, and has written Dummies books on NetWare and Windows Server with Ed. He has also worked as a trainer, a technical evangelist, and a network management and deployment specialist for such companies as IBM, NimSoft and Northrup-Grummond.