Publishing Virtual Desktop Pools

Introduction Publishing Virtual Desktop Pools

Version: Horizon View 5.1

View has always had a concept of virtual desktop pools. At the simplest level, a pool is just a grouping of resources the user can access, these can be virtual desktops, blade PC’s or terminal servers. Depending on your settings, pools fall into two main types – an Automated Pool or Manual Pool. With an automated pool, virtual desktops are created upfront for a number of users, and then on-demand as more users access the desktops. Below is a bulleted list which outlines the pool types, and what features are supported with them:

  • Automated Pool – For virtual desktops only and supports Local Mode, PCoIP and Persona Management – and critically supports the View Composer Linked Mode feature. With the automated pool there are two modes called Dedicated and Floating which used to be called Persistent and Non-Persistent mode. Although the terms have changed, they essentially mean the same thing. With Dedicated mode, the user grabs a virtual desktop from the pool, and it remains theirs forever. With a Floating pool, a user is still allocated a virtual desktop, but when the user logs out, the virtual desktop is handed back to the pool to be used by another user. Floating pools are closely aligned with a more concurrency-based perspective of providing virtual desktops – you only need the number of virtual desktops that match the total concurrent load (with perhaps extras for unexpected peaks) at any one time. As you might expect, the desktop has to be locked down with policies and other tools, especially when the user is never returned to the same desktop. It’s worth mentioning that you cannot switch a Dedicated pool to being a Floating pool, or vice versa.

In recent years there’s been a strong debate in the community about the merits of using Dedicated (often referred to as persistent desktops) and Floating (often referred to non-persistent desktop). For many the Dedicated desktop looks/feels more like a conventional laptop/PC. The user has dedicated disk with chunk of storage, if they make changes they are permeant. With the cost of storage going down, and the performance of storage going up – increasing some people regard standard images (rather than linked clones) with dedicated desktops a better user experience than a linked-clone model using floating pools. Historically, this model has been used to reduce the disk footprint of the virtual desktop, speed up the cloning process and focused on a more concurrency approach for sessions – to reduce the cost of a virtual desktop environment. However, that has often come with penalty of reduced performance, and a less slick user experience.

  • Manual Pool – For virtual desktops and physical computers such as blade PCs. Manual pools support all the features of an Automated pool except, critically, View Composer Linked Mode is not supported, however the local mode feature is supported.
  • Terminal Services Pool – None of the advanced features are supported, so, critically, there is no PCoIP support for these legacy RDP-enabled systems.
Desktop Pools – Requirements and Best Practices

Before we begin to look at Virtual Desktop Pools, we should discuss some of the requirements and best practices. Firstly, examine your group structures in Active Directory – you may wish to create a group structure specifically for assigning the right users to the right virtual desktop pool. Secondly, you might want to create a similar structure in vCenter of resource pools and virtual machine folders to keep your VMware View environment separate and distinct from the rest of your virtual infrastructure. The screen grabs below show our configuration:



As you can see, we have both a resource pool and virtual machine folder structure for the VMware View environment. Win7 and WinXP are our test virtual desktops that we will convert into templates to form the basis of our virtual desktop pools. The desktop pool feature uses templates, Microsoft Sysprep and the guest customization configurations to automate the bulk creation of virtual desktops. As such, we advice that you should always test your templates and the guest customization configurations to make sure they work before you even think about creating a virtual desktop pool.

The guest customization stored in vCenter must be DHCP based otherwise it will not be shown. VMware View assumes all your virtual desktops will be configured as DHCP clients. Additionally, we found with Windows 7 that we had to the use the full FQDN values to make sure it successfully joined our CORP.COM domain:


Important: One of the most common mistakes we have seen is folks forgetting that when they make a virtual machine into a template, everything about the VM is captured as part of the template – including connected CD-ROMs and floppy disks, it is actually recommended that you remove the floppy and CD ROM drives from your master image as they will not be required . Additionally, in the Guest Customization Wizard it is possible to store a password to reset the Administrator password in Windows. These passwords are protected by encryption by using a public key. For this to function properly, the user account used by VMware View to communicate with vCenter must have rights to the Guest Customization Settings.

Finally, a word about the VMware Guest Customization wizard – currently it has no method to control where the computer accounts of the virtual desktops are located. This is especially important in the context of VDI as the correct location of computer accounts in your AD structure is necessary if you are using Microsoft Group Policy objects. VMware does have a method to achieve this, but only if you use the Linked Clones feature. If you are not using this feature from VMware, you might want to investigate the use of Microsoft’s sysprep.inf files. These syprep.inf files do support the placement of the computer account into the desired Organizational Unit in Active Directory. If you are using Windows XP, you still create sysprep.inf files using the Setup Manager located in the \support\ file on the Windows XP CD. In Windows XP, the sysprep.inf file supports a MachineObjectOU parameter that uses the Distinguished Name syntax to indicate the location of the computer account. This is manually added to the sysprep.inf file in the [Identification] section beneath the details that outline how it will be joined to the domain:





MachineObjectOU=OU=Accounts, OU=Virtual Desktops, DC=CORP, DC=com

If, on the other hand, you intend to deploy Windows 7, you will need to download and install the appropriate Windows Automated Installation Kit (WAIK) for the client operating system. For Windows 7 you can find its WAIK here:

Once you have created your sysprep.inf file and made the necessary changes, the file can be imported into vCenter by navigating to the Guest Customization manager in the Home location under the Management section.


Publishing a Dedicated Desktop Pool

Once you are happy the above is in place, we’re ready to publish the desktop. In this format, the desktops created will be assigned to a group of users. Once a user has logged on and acquired the desktop, it will belong to them and cannot be used by another person in the organization

1. Login to the Administrative webpage of the Connection Server

2. Open >Inventory

3. Select the Pools node

4. Click the Add… button

5. In the pool type select the option called Automated Pool

6. In the User Assignment page, select Dedicated as the method, and leave Enable automatic assignment as the option


Remember, with the Dedicated desktop, the user is initially randomly assigned a virtual desktop from the pool, but subsequently always returns to the same desktop.

7. In the vCenter page, select the option called Full virtual machines


We will look at Linked Clone-enabled pools shortly. Notice how our vCenter is not yet enabled for the Linked Clone feature


8. Select the vCenter(s) which manages the virtual desktop

9. Next, you must specify a unique ID for this virtual desktop pool, together with some friendly information by which the end user will be able to identify the virtual desktop. In our case we set a unique ID of SalesGroupWin7, with a friendly name of Sales Group Windows 7 Desktop


10. The next page allows you to control some per-virtual desktop settings which centre around the end user connection


Many of these settings are self-explanatory. But in an effort to remain complete, the table below explains each setting, what it does and the consequences of each selection. You’re welcome to bypass this table and move on to the next part of the wizard if you so wish.

Screen Shot 2014-04-30 at 09.12.57.png

11. The Provisioning Settings page controls how the virtual desktops will be created in the pool.


The Basic options include “Enable provisioning”. With this setting ticked, after clicking Finish in the web admin wizard, the creation of the virtual desktops in the pool will begin automatically. The “Stop provisioning on error” option will halt the creation of the pool if a significant error occurs, such as running out of space in the datastore.

The Virtual Machine Naming options are used to set the base virtual machine name in vCenter and also the NETBIOS name of Windows as the desktops are created. This names and creates a folder in vCenter to contain the virtual desktops. We would avoid the “Specify names manually” option, as this means that each VM created has to have its NETBIOS name set by hand by interacting with the Sysprep Mini-Installation wizard. The option to “Use a naming pattern” is the one to go for, as it will take the text provided and serialize each desktop created in the form of salesdesktop1, salesdesktop2 and so on. Optionally, it is possible to include a unique number anywhere in the string with the {n} value to set this number – we could use sales{n}desktop to generate a pattern of sales1desktop, sales2desktop and so on. To avoid your VM’s appearing miss-ordered in the vSphere client for example VM1, VM10, VM2, VM3 etc you are able to set a fixed length for the unique numbers. You are able to adjust the {n} value as follow {nixed=2} this will ensure that there are two numbers appended so you will end up with the VM’s being named VM01, VM02 and so on. You are also able to set this value to {n:fixed=3} for larger pools, please note if you set {n:fixed=) to 1 the maximum field length is 14, setting it to 2 the maximum field length is 13 and finally to 3 the maximum field length is 12.

The Pool Sizing options allow you to set a Maximum, Number of spare powered on desktops and Minimum number of desktops. These are used to set a hard limit so you don’t get hundreds and thousands of desktops created. They also allow you to create a buffer (or idle pool) of virtual desktops ready to be connected to, so users don’t have to wait while a desktop is created when they log on – it will be ready and waiting for them. In our case, the absolute maximum number of virtual desktops is 50, after clicking Finish, 5 virtual desktops will be created. Once these 5 desktops have been allocated, VMware View will create another 2. The idea of this is to create only the number of desktops you initially need (5). As your organization grows and employs new users, it will generate the additional virtual desktops needed (2). However, because you will run out of disk or memory you have capped this growth to a maximum of 50 virtual desktops. These fields contain validation so it is impossible to set something that is illogical; the screen grab below shows this. In this case we have asked for a minimum that is larger than our maximum – with no spare or reserve virtual machines.


In our case to save disk space and time we actually used 10,2,2 for the settings. This meant we wouldn’t need too many clients (3) before we began to see the minimum and spare values spawn new desktops as our user-base grew.

12. Next, in the vCenter Settings page we can select the template that will form the basis of the Automated Dedicated Virtual Desktop pool. Each select button allows you to browse the vCenter specified earlier to indicate where the VMs should be located in terms of the vCenter Folders, Cluster and Resource Pool.


By far the most interesting select button is the datastore options.

13. Select a storage location. The somewhat cryptic warning at the bottom of this dialog box is a reminder that you don’t just need space for the virtual disks of the virtual desktops, but also their swap files as well. It is possible to select more than one datastore in this list, and if you do this, View will distribute the virtual desktops across the datastores selected


Shared datastores are recognisable by the cyclinder with a pipe symbol. In our case, we have selected a VMFS volume on our SAN which has 1,944GB of free space. View warns you that this is less than the recommended minimum volume size of 2,000GB, this figure is calculated by the size of your template multiplied by the maximum number of desktops you have selected. The “Select Datastores” window allows you to select more than one datastore simultaneously – the system interprets this by aggregating all the storage selected.

14. As previously in the post-configuration steps – new in Horizon View 5.1 was the ability to enable host cache, as well as enabling host cache in the configuration we also need to enable it when creating or editing pools. By enabling host cache it will mean ESXi is able to store the most regularly read blocks in memory to reduce the demand for reads on the storage. We can also see here that it is possible to tweak how often the cache is regenerated or forcefully stop the regeneration of cache during busy periods to ensure there is no loss of performance when it is most needed. Because the regeneration of the cache is a CPU intensive operation it is recommended that you create a blackout period to cover your working hours to ensure regenergation happens out of hours.


15. We now need to select a Guest Customization for the correct operating system that joins the virtual desktop to a valid Microsoft Active Directory domain


Clicking Finish will trigger the provisioning process and also create a folder to hold the virtual desktops created in the pool. So to be 100% clear View Pools will automatically create a folder, but does not automatically create resource pools.

Finally, configure the VMware View rights to allow the Sales AD group to access the desktop.



16. Select the virtual desktop pool option from the Inventory menu


Note that the icons in this view can give you an indication of possible problems in the wider environment. For example, if the vCenter server is unavailable for whatever reason, the View administration console will show a red X next to the affected pool(s):


Once the desktop has been added it should appear in the list, and will display with a solid line around the icon if it is a dedicated pool like this:

Screen Shot 2014-04-30 at 09.29.48.png where as the manual pool icons looks like this Screen Shot 2014-04-30 at 09.29.59.png

17. Select the Entitlements menu from the top of the Pools view

18. In the Entitlements pop-up page, click the Add button

19. Disable the filter on Users, and Enable the filter on Groups

20. Click the Find button and locate the correct group, in our case Sales Group

In our group model, we used the Virtual Desktop User group to handle the Windows rights required for access to Microsoft RDP, and membership of a functional user group (Sales, Accounts, Distribution) to handle access to a particular desktop pool. Of course there are many, many different ways to handle the group structures depending on the size of your organization, and the complexity of the end-user base. As a test, we have created a user called “salesuser0N” and added him to both the View Desktop User group and Sales User group. Fundamentally, membership of both groups is required in our case for this user to connect.  

Publish a Floating Virtual Desktop Pool

Automated Floating Virtual Desktop Pools are set up in a very similar way to Automated Dedicated pools. They differ in one crucial respect – the user is merely allocated a virtual desktop when they log on, and when they log off we can optionally configure view to delete the virtual desktop and create a new desktop. This has the net effect of giving the user a clean environment every time they login. This can be helpful in kiosk-style environments like a school or college, which are somewhat notorious for being meddled with by teenagers who think downloading screen grabs of Pamela Anderson (maybe we are showing our age now!) and leaving them as desktop backgrounds is very funny! Of course, one way to defeat these miscreants is by locking down the desktop with policies to the degree that they can do next to nil to tamper with their environment. Due to its volatile nature, it is imperative that users of non-persistent virtual desktops are not able to save files on the desktop or on the C: drive. If they do, when they log off the data will be lost forever.

By now you are probably very familiar with the pages of VMware View web administration, so we will keep screen grabs down to an absolute minimum in the following instructions:

1. Login to the Administrative webpage of the Connection Server

2. Open the >Inventory

3. Select the Pools node

4. Click the Add… button

5. In the pool type select the option called Automated Pool

6. In the User Assignment page, select Floating as the method

7. In the vCenter page select the option called Full Virtual Machines

8. Select the vCenter(s) which manages the virtual desktop

9. Next you must specify a unique ID for this virtual desktop pool together with some friendly information by which the end-user will be able to identify the virtual desktop. In our case we set an unique ID of Student, with a friendly name of Student Desktop

10. In the Pool Settings notice how a new option has appeared called Delete desktop after logoff


11. In the Provision Settings page, set your configuration as deemed appropriate for the levels of concurrency you expect to see in this pool. You may wish to dispense with setting a “Min number of desktops” and keep the option to “Provision all desktops up-front”. The choice is yours.

12. In the vCenter Settings page, select the Template, VM Folder, Cluster, Resource Pool and Datastore for this new pool

13. Finally, select a Guest Customization Specification suitable for your domain and operating system

Floating pools appear with dashed line around the icon for the pool like so:

Screen Shot 2014-04-30 at 09.54.44.png


In this chapter we have covered one of the key concepts of VMware View creating desktop pools, you will find in most scenarios you will try to create a floating pool over and above a dedicated pool. With a floating pool you have the most freedom for the users and normally you will split their profile away from the virtual desktop making the desktops disposable rather than needing to worry about ensuring they are backed up. We are not yet done with virtual desktop pools – they form the bedrock of the View software – and so we will be touching upon them and their settings throughout this book. In our next chapter were going to look more closely at managing desktop pools.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s