GPUs Should Be Optional for VDI

Note: I disabled comments on my blog in 2014 because of spammers. Please comment on this discussion on Twitter using the #VDIGPU hashtag.

Brian Madden recently published a blog arguing that GPU should not be considered optional for VDI.  This post stemmed from a conversation that he had with Dane Young about a BriForum 2015 London session on his podcast

Dane’s statement that kicked off this discussion was:
”I’m trying to convince people that GPUs should not be optional for VDI.”

The arguments that were laid out in Brian’s blog post were:

1. You don’t think of buying a desktop without a GPU
2. They’re not as expensive as people think

I think these are poor arguments for adopting a technology.  GPUs are not required for general purpose VDI, and they should only be used when the use case calls for it.  There are a couple of reasons why:

1. It doesn’t solve user experience issues: User experience is a big issue in VDI environments, and many of the complaints from users have to do with their experience.  From what I have seen, a good majority of those issues have resulted from a) IT doing a poor job of setting expectations, b) storage issues, and/or c) network issues.

Installing GPUs in virtual environments will not resolve any of those issues, and the best practices are to turn off or disable graphics intensive options like Aero to reduce the bandwidth used on wide-area network links.

Some modern applications, like Microsoft Office and Internet Explorer, will offload some processing to the GPU.  The software GPU in vSphere can easily handle these requirements with some additional CPU overhead.  CPU overhead, however, is rarely the bottleneck in VDI environments, so you’re not taking a huge performance hit by not having a dedicated hardware GPU.

2. It has serious impacts on consolidation ratios and user densities: There are three ways to do hardware graphics acceleration for virtual machines running on vSphere with discrete GPUs.

(Note: These methods only apply to VMware vSphere. Hyper-V and XenServer have their own methods of sharing GPUs that may be similar to this.)

  • Pass-Thru (vDGA): The physical GPU is passed directly through to the virtual machines on a 1 GPU:1 Virtual Desktop basis.  Density is limited to the number of GPUs installed on the host. The VM cannot be moved to another host unless the GPU is removed. The only video cards currently supported for this method are high-end NVIDIA Quadro and GRID cards.
  • Shared Virtual Graphics (vSGA): VMs share access to GPU resources through a driver that is installed at the host level, and the GPU is abstracted away from the VM. The software GPU driver is used, and the hypervisor-level driver acts as an interface to the physical GPU.  Density depends on configuration…and math is involved (note: PDF link) due to the allocated video memory being split between the host’s and GPU’s RAM. vSGA is the only 3D graphics type that can be vMotioned to another host while the VM is running, even if that host does not have a physical GPU installed. This method supports NVIDIA GRID cards along with select QUADRO, AMD FirePro, and Intel HD graphics cards.
  • vGPU: VMs share access to an NVIDIA GRID card.  A manager application is installed that controls the profiles and schedules access to GPU resources.  Profiles are assigned to virtual desktops that control resource allocation and number of virtual desktops that can utilize the card. A Shared PCI device is added to VMs that need to access the GPU, and VMs may not be live-migrated to a new host while running. VMs may not start up if there are no GPU resources available to use.

Figure 1: NVIDIA GRID Profiles and User Densities

There is a hard limit to the number of users that you can place on a host when you give every desktop access to a GPU, so it would require additional hosts to meet the needs of the VDI environment.  That also means that hardware could be sitting idle and not used to its optimal capacity because the GPU becomes the bottleneck.

The alternative is to try and load up servers with a large number of GPUs, but there are limits to the number of GPUs that a server can hold.  This is usually determined by the number of available PCIe x16 slots and available power, and the standard 2U rackmount server can usually only handle two cards.   This means I would still need to take on additional expenses to give all users a virtual desktop with some GPU support.

Either way, you are taking on unnecessary additional costs.

There are few use cases that currently benefit from 3D acceleration.  Those cases, such as CAD or medical imaging, often have other requirements that make high user consolidation ratios unlikely and are replacing expensive, high-end workstations.

Do I Need GPUs?

So do I need a GPU?  The answer to that question, like any other design question, is “It Depends.”

It greatly depends on your use case, and the decision to deploy GPUs will be determined by the applications in your use case.  Some of the applications where a GPU will be required are:

  • CAD and BIM
  • Medical Imaging
  • 3D Modeling
  • Computer Animation
  • Graphic Design

You’ll notice that these are all higher-end applications where 3D graphics are a core requirement.

But what about Office, Internet Explorer, and other basic apps?  Yes, more applications are offloading some things to the GPU, but these are often minor things to improve UI performance.  They can also be disabled, and the user usually won’t notice any performance difference.

Even if they aren’t disabled, the software GPU can handle these elements.  There would be some additional CPU overhead, but as I said above, VDI environments usually constrained by memory and have enough available CPU capacity to accommodate this.

But My Desktop Has a GPU…

So let’s wrap up by addressing the point that all business computers have GPUs and how that should be a justification for putting GPUs in the servers that host VDI environments.

It is true that all desktops and laptops come with some form of a GPU.  But there is a very good reason for this. Business desktops and laptops are designed to be general purpose computers that can handle a wide-range of use cases and needs.  The GPUs in these computers are usually integrated Intel graphics cards, and they lack the capabilities and horsepower of the professional grade NVIDIA and AMD products used in VDI environments. 

Virtual desktops are not general purpose computers.  They should be tailored to their use case and the applications that will be running in them.  Most users only need a few core applications, and if they do not require that GPU, it should not be there.

It’s also worth noting that adding NVIDIA GRID cards to servers is a non-trivial task.  Servers require special factory configurations to support GPUs that need to be certified by the graphics manufacturer.  There are two reasons for this – GPUs often draw more than the 75W that a PCIe x16 slot can provide and are passively cooled, requiring additional fans.  Aside from one vendor on Amazon, these cards can only be acquired from OEM vendors as part of the server build.

The argument that GPUs should be required for VDI will make much more sense when hypervisors have support for mid-range GPUs from multiple vendors. Until that happens, adding GPUs to your virtual desktops is a decision that needs to be made carefully, and it needs to fit your intended use cases.  While there are many use cases where they are required or would add significant value, there are also many use cases where they would add unneeded constraints and costs to the environment. 

Horizon View 6.0 Load Balancing Part 1#VDM30in30

Redundancy needs to be a consideration when building and deploying business critical systems.  As user’s desktops are moved into the data center, Horizon View becomes a Tier 0 application that needs to be available 24/7 as users will not be able to work if they can’t get access to a desktop.

Horizon View is built with redundancy in mind.  A single View Pod can have up to 7 Connection Servers to support 10000 active desktop sessions, and the new View Cloud Pod features allows up to four View Pods to be stretched across two geographic sites.

Just having multiple connection servers available for users isn’t enough.  That doesn’t help users if they can’t get to the other servers or if a load-balancing technology like DNS Round Robin tries to send them to an offline server.

Load Balancers can be placed in front of a Horizon View environment to distribute connections across the multiple Connection Servers and/or Security Servers.  There are some gotcha’s to be aware of when load balancing Horizon View traffic, though.

VMware doesn’t appear to provide any publicly available documentation on load balancing Horizon View traffic, and most of the documentation that is available appears to be from the various load balancing vendors.  After reading through a few different sets of vendor documentation, a few commonalities emerge.

Horizon View Network Communications

Before we can go into how to load balance Horizon View traffic , let’s talk about how clients communicate with the Horizon View servers and the protocols that they use.

There are three protocols used by clients for accessing virtual desktops.  Those protocols are:

  • HTTPS – HTTPS (port 443) is used by Horizon clients to handle  user authentication and the initial communications with the Connection or Security server.
  • PCoIP – PCoIP (port 4172) is the remote display protocol that is used between the Horizon Client and the remote desktop. 
  • Blast – Blast (port 8443) is the remote display protocol used by HTML5-compatible web browsers.

Remote Desktop Protocol (RDP) is also a connectivity option. 

When a user connects to a Horizon View environment using either the web client for Blast or the Horizon Client application for PCoIP, the initial communications take place over HTTPS.  This includes authentication and the initial pool or application selection.  Once a pool or application has been selected and the session begins, communications will switch to either Blast or PCoIP.

In the example above, the user connects to the fully-qualified domain name of the security server.  After authenticating, they select a pool and connect using the protocol for that pool.  If they’re connecting over PCoIP, they connect to the IP address of the server, and if they connect over Blast, the connection goes through the URL of the server. 


The URLs used by clients when connecting through a security server.  The PCoIP URL is the external IP address used by the server.

When a load balancer is inserted into an environment to provide high availability for remote access, things change a little.  The initial HTTPS connection hits the load balancer first before being distributed to an available connection or security server.  All PCoIP and/or Blast traffic then occurs directly with the security server.


This can have some implications for the certificates that you purchase and install on your servers, especially if you plan to use Blast to allow users to access desktops from a web browser.  If you choose not to use HTTPS offloading, the certificate that is installed on the load balancer also needs to be installed on the security servers.  This may require a SAN certificate with the main external URL and the Blast URLs for all servers.

Load Balancing Requirements

There are a few requirements for load balancing your Horizon View environment.  These requirements are:

  • At least 2 Security or Connection Servers
  • A load balancer that supports HTTPS persistence, usually JSESSIONID

If you’re load balancing external connections, you’ll need an IP address for each security server and an IP address for the load balancer interface.  If you have two security servers, you will need a total of three public IP addresses.

In an upcoming post, I will walk through the steps of load balancing a Horizon View environment using a Kemp virtual Load Master.

Horizon View 6.0 Application Publishing Part 5: Manually Publishing an Application

The last post covered the process of creating an application pool using applications that have been installed on the server and are available to all users through the start menu.  But what if the application you need to publish out is not installed for all users or not even installed at all?

The application that needs to be published out might be a simple executable that doesn’t have an MSI installer.  It could be a ThinApp package located on a network share.  Or it could even be a web application that needs to be accessed from non-secure environments.  Whatever the reason, there may be times where an application will need to be published out that isn’t part of the default application list.

The steps for manually publishing an application are:

1.  Log into View Administrator

2.  In the Inventory panel, select Application Pools.


3. Click Add to create a new pool.


4. Select the RDS Farm you want to create the application in from the dropdown list and then click “Add application pool manually.”


5. Enter the following required fields.:

  • ID – The pool ID.  This field cannot have any spaces.
  • Display Name – This is the name that users will see in the Horizon Client.
  • Path – The path to the application executable.  This must be the full file path of the executable.
  • Description – A brief description of the application.


The following parameters are optional:

  • Version – The version number of the application
  • Publisher – The person or company that created or published the application
  • Parameters – Any command line parameters that need to be passed to the application executable. 

6. Make sure that the Entitle Users box is checked and click Finish.


7. Click Add to bring up the Find User or Group wizard.


8. Search for the Active Directory user or group that should get access to the application.  Select the user/group from the search results and click OK.


9. Click OK to finish entitling users and/or groups to pools.

10. Log into your Horizon environment using the Horizon Client.  You should now see your published application as an option with your desktop pools.

Note: You need to use version 3.0 or later of the Horizon client in order to access published applications.  Published applications are not currently supported on Teradici-based zero clients.


Horizon View 6.0 Application Publishing Part 3: Creating An RDS Farm #VDM30in30

The previous post covered the steps for configuring a Windows Server with the Remote Desktop Session Host role and installing the Horizon View agent.  There is one more step that need to be completed before applications can be published out.

That step is creating the server farm.  In Horizon View terms, a farm is a group of Windows Servers with the Remote Desktop Services role.  They provide redundancy, load balancing, and scalability for a remote desktop pool, multiple published application pools, or both for a group of users.

The steps for setting up an RDS Farm are:

1. Log into View Administrator

2. In the Inventory side-panel, expand Resources and select Farms.


3. Click Add to create a New RDS Farm.


4.  Enter a name for the pool in the ID field and a description for the pool.  The name cannot have any spaces.  Click Next to continue.

You can also use this page to configure the settings for the farm.  The options are:

  • Default Display Protocol – The default protocol used by clients when connecting to the application
  • Allow users to choose protocol – Allows users to change the protocol when they connect to their applications
  • Empty SessionTimeout – the length of time a session without any running applications remains connected
  • Timeout Action – Determine if the user is logged out or disconnected when the Empty Session Timeout expires.
  • Log Off Disconnected Sessions – Determines how long a session will remain logged in after a user has disconnected their session


5. Select the RDS host or hosts to add to the Farm and click next to continue.


6. Review the settings and click Finish.


Once you have a farm created and an RDS host assigned, you can create application pools.  This will be covered in the next article in this series.

Horizon View 6.0 Application Publishing Part 2: Building Your Terminal Servers #VDM30in30

The application publishing feature of Horizon 6.0 utilizes the capabilities of the Remote Desktop Session Host role.  This requires servers with the role installed and licensed in order to publish applications.

Sizing RDS Servers

There isn’t a lot of guidance from VMware on sizing servers for application publishing.  Microsoft guidelines for sizing the Remote Desktop Session Host can be used, though.  The Microsoft recommendations are:

  • 2 GB of RAM for each CPU core allocated to the system
  • 64 MB of RAM for each user session
  • Additional RAM to meet the requirements of the installed applications

With these guidelines in mind, a server that has 4 vCPUs and sized for 50 users would need 11 GB of RAM allocated before accounting for additional RAM to support application requirements.

The local system drive should be large enough to accommodate the user profiles for all logged in users, temporary files, and other application data.  Drive space should be monitored carefully, and unneeded log, temp, and data files should be cleaned up periodically.

Group Policy Settings

There is a good chance that you will have more than one RDSH server in your application publishing pool.  Group Policy should be used to ensure consistent configuration across all servers in the pool.  A number of Remote Desktop Services specific policies, such as restricting users to a single session, can only be configured using group policy in Server 2012 R2.  Specific Group Policy guidelines for application publishing will be covered in another article.

Building and Deploying A Server

When you’re building up a server image for Terminal Servers, you should consider building up a new server image (or deploy from an existing barebones template), install the Remote Desktop Session Host role, and configure your base applications.  This will allow you to quickly deploy RDS servers more quickly than if you would have to build them from scratch and install your business applications on them.  This will also require periodic template maintenance to ensure that all of the Windows patches and applications are up to date.

There are already a few good walkthroughs on how to configure a new Windows Server 2012 R2 template, so I won’t cover that ground again.  One of my favorites can be found in this great article by Michael White.

While building or deploying your template, it is a good idea to not install any applications until after the Remote Desktop Session Host role has been installed.  Applications that are installed before the RDSH role is installed may not work properly.

Once you have your template built, or once you have deployed a new VM from an existing Windows template, we need to take the following steps to prepare the server to publish applications:

1. Connect into the new server using Remote Desktop

2. Launch the Server Manager

3. Click Manage –> Add Roles and Features


4. Click Next to go to the Installation Type screen

5. Select Role-based or feature based Installation and click Next


6. On the Server Selection page, click Next.  This will select the server that you’re currently logged into.

Note: It is possible to install and configure Remote Desktop Services remotely using Server 2012 or Server 2012 R2.  This can be accomplished using the Server Manager.

7. Check the box for the Remote Desktop Services role and click Next


8. Expand the .Net Framework 3.5 Features and check the .Net Framework 3.5 (includes .NET 2.0 and 3.0) box to select it.

Note: This step is not required for installing the RDSH role.  I like to install this feature now, before adding the RDSH role, because many applications still require .Net 3.5.


9. Scroll down to User Interfaces and Infrastructure and expand this list.

10. Check the box next to Desktop Experience. and click next.

Note: Desktop Experience is not required.image

11. Click Next to go to the Remote Desktop Role Services page.

12. Check the checkbox for Remote Desktop Session Host.  If prompted to install additional features, click Add Features and click Next to continue.


13. Click Install to being the Role and Feature installation.

14. Reboot the server when the installation has finished.

15. Once the installation is complete, open a Command Prompt as an administrator and enter: change user /install  .  This command puts the RDSH server into software installation mode.


16. Install any business or end-user applications.  Once you have completed installing any applications, enter: Change User /Execute.

Installing the Horizon Agent

The last step is to install the Horizon View Agent onto the Remote Desktop Services host.  The process for installing the agent is similar to installing it on a desktop virtual machine, but there are some differences in this process.

The steps for installing the View Agent are:

1. Double click the installer to launch it.

2. Click Next on the Welcome screen.


3. Accept the license agreement and click Next.


4. Select the options that you want to install and the directory to install to and click Next.


5. Enter the Fully Qualified Domain Name or IP address of a Connection Server in your environment in the textbox labeled Server.

If the account that you’re logged in with has permission to add the server to the View environment, select the “Authenticate as Current User” option, otherwise select “Specify Administrator Credentials” and provide an account with the correct permissions.  Click Next to continue.


6. Click Install to install the View Agent.


7. Click Finish when the installation has completed.


8. The server will prompt for a reboot.  Click Yes to reboot the server.


The agent will be completely installed when the reboot completes.  But the server will not be available in Horizon View just yet.  Before it can be used to publish applications, a Farm and an Application Pool need to be configured.

In the next post, we’ll go over how to set up a Farm inside of View Administrator.

Revisiting The Horizon View Start-Recompose Script #VDM30in30

Last September, I posted a script that I had written to address a few issues in the Horizon View environment that I managed at the time.  At the time, I had seven base images for sixteen desktop pools, and scheduling the Patch Tuesday recompose operations would take half the day if I had to do it manually in View Administrator.

After the script was posted, I learned that there were several issues with it.  While it had worked in the environment I originally wrote it for, I hadn’t properly documented all the parameters in the comment-based help.  This was causing odd failures when attempting to run the script.

A couple of weeks ago, I received an email from someone who was hoping to use the script in their environment.  They were experiencing issues with running the script, and after helping them with their issue, I decided to revisit the script and fix the issues.

The changes in this version of the script are:

  • Changed the way that the View LDAP database is queried so the Quest AD cmdlets are no longer required
  • Removed the Replica Parameter. The script will now detect the correct replica volume from the Pool settings
  • Renamed the View parameter to ConnectionServer to better describe what its for
  • Made the vCenter, ConnectionServer, and ParentVM parameters mandatory.
  • Fixed the comment-based help so all parameters are listed and examples provided.
  • Removed all email notification code from the script

You can download the latest version of the Start-Recompose PowerShell script from my Github site.

Horizon View 6.0 Application Publishing Part 1: Introduction #VDM30in30

One of the advantages that Citrix had over VMware in the EUC space was the ability to just publish specific applications to users with the MetaFrame/Presentation Server/XenApp line of products.  This suite utilized the Microsoft Terminal Services/RDSH roles on Windows Server to present users with centrally hosted and managed applications as if those applications were installed locally on their computer.

Application publishing was one of the new features that VMware added in Horizon 6.0 when it was released earlier this summer.  Like XenApp, this feature relies upon Windows Servers with the Remote Desktop Session Host role. 

The new application publishing feature reuses a lot of the infrastructure that is deployed to support virtual desktops.  This feature utilizes the same connection servers and security servers as the virtual desktop environment, and access to the published applications is done through the Horizon Client.    This provides a single point of management for the entire environment.

Why Publish Applications?

Application publishing technology is not new.  Citrix and Microsoft have both had versions of this technology for some time.  Many of the reasons for using those programs also apply to the Horizon application publishing feature.

The most common reasons I know of for publishing out applications are;

  • You want to centrally manage and provide access to core/critical Windows desktop business applications
  • You work in multiple locations and want applications to follow you – such as medical personnel in a hospital
  • You want to provide secure access to specific applications to remote users.

These are just a few of the reasons to publish out applications, and that list is by no means exhaustive. 


The licensing model for publishing applications from servers using Remote Desktop Services is different from the licensing model for virtual desktops.  Like virtual desktops, Remote Desktop Services is not covered under the standard Windows licensing, and Microsoft requires separate RDS CALs to enable this feature on Windows Servers. 

A separate license server is required to manage the RDS CALs.  If this license server is not available, the RDSH services will shut down after the trial period expires.  Configuring the RDS license server is beyond the scope of this series, but there is a good walkthrough here.

More information on licensing Remote Desktop Services can be found on the Microsoft site, and you should contact your Microsoft licensing rep if you have any questions.  The whitepaper in the link also covers licensing Microsoft desktop applications such as Office in RDS environments.

Up Next

The next article in this series will cover how to configure a Windows Server as an Remote Desktop Session Host and add it into Horizon View as an application host.  Publishing out applications will be covered after that, and the final article in this series will cover how to access published applications from within a Horizon View virtual desktop.

Enabling Windows Server 2008 R2 Desktops in Horizon 6 #VDM30in30

VMware introduced support for Windows Server 2008 R2 virtual desktops in Horizon View 5.3.  This support wasn’t enabled out of the box.  It required an administrator to edit the View LDAP database to enable the feature and a special command-line only installation of the agent on the target desktop.

Horizon View 6 brought many new changes, including better support for Windows Server desktop.  The first patch set also added better support for this feature.

Why Use Windows Server 2008 R2 as a Desktop OS?

Historically, Microsoft licensing for virtual desktops has been a pain.  In the past, it required connecting endpoints to be covered under software assurance or users to be covered under expensive subscription-based licensing, and there were no service provider licensing options.

Although some of this appears to be changing with the latest per-user licensing SKUs that will be available on December 1st, 2014, the service provider side still hasn’t been fixed.

From a cost perspective, there are some benefits as well.  Windows Server Data Center licensing allows for unlimited Windows instances on licensed virtual hosts.  This can generate significant savings compared to VDA subscriptions.

Note: I am not an expert on Microsoft licensing, and the features and terms of Microsoft’s licensing can change frequently.  Please contact your Microsoft representative if you have any questions on licensing products for virtual desktop environments.

Enabling Windows Server 2008 R2 Desktop Support

Enabling Windows Server 2008 R2 desktop support have been streamlined from Horizon View 5.3, and manual edits to the LDAP database are no longer required.

The steps to enable this support are:

1. Log into the Horizon View Administrator console.

2. Go to View Configuration –> Global Settings

3. Click Edit.

4. Check the Enable Windows Server 2008 R2 Desktops checkbox and click OK.


Installing the Horizon View Agent

The process for installing the View Agent on Windows Server desktops has also been streamlined.  Installing the agent in View 5.3 required a command-line installation with a special switch to force the installer into desktop mode as the installer was geared for servers with the RDSH role. 

That has changed as well, and the installation process for Server 2008 R2 desktops is now the same as installing it on Windows 7/8/8.1 virtual desktops.

Horizon view 6.0 Part 12–Installing and Configuring A Security Server #VDM30in30

Horizon View provides a secure method for granting users access to their desktops from anywhere with an Internet connection on any device without needing a VPN connection.  Now that a desktop pool has been set up and desktops are provisioned, it’s time to set up that remote access.

The Security Server

The View Security Server is VMware’s method of addressing remote access.  This component of the Horizon View environment contains a subset of the Connection Server components, and it is designed to sit in a DMZ and act as a gateway for Horizon View Clients.  It’s essentially a reverse proxy for your View environment.

Each Security Server that is deployed needs a corresponding Connection Server, and they are paired during the installation process.  Because the Security Server is an optional component, each Connection Server is not required to have one, and a Connection Server cannot be paired to more than one Security Server.

Each Security Server also needs a static IP address.  If it is externally facing, it will need to have a publicly addressable static IP.  This IP address does not need to be configured on the server’s network card as both Static 1:1 NAT and PAT work with Horizon View.

Security Server Firewall Ports

In order to enable remote access, a few ports need to be opened on any firewalls that sit between the network where the Security Server has been deployed and the Internet.  If the server is deployed into a  DMZ, the firewall will also need to allow traffic between the Security Server and the Connection Server.

The rules that are required on the front-end, Internet-facing firewall are:

  • HTTP – TCP 80 In
  • HTTPS – TCP 443 In
  • HTTPS – TCP 8443 both directions (if Blast is used)
  • PCoIP – TCP 4172 In, UDP 4172 both directions

If you are deploying your Security Servers in a DMZ configuration with a back-end firewall, you need to configure your firewall to allow IPSEC traffic to the Connection Servers.  These rules depend on whether network address translation is used between the DMZ and Internal network.  For more information on the rules that need to be enabled, please see this VMware KB article.

The Security Server will also need to communicate with the Horizon View desktops.  The following ports will need to be opened to facilitate this:

  • PCoIP – TCP/UDP 4172 both directions

Note: If you’re using application-aware firewalls like Palo Alto Networks devices, make sure that any application protocols required by Horizon View aren’t blocked between the DMZ and Internal network.  Also, updates to the application signatures or the PCoIP protocol may impact users’ access to virtual desktops.

Configuring Horizon View for a Security Server

The Security Server installation will prompt for a Connection Server to be paired with and a pairing password during the install process.  This must be set up before the installation starts.  To set up the pairing password, take the following steps:

1. In View Administrator, go to View Configuration –> Servers

1. View Configuration

2. Click on the Connection Servers tab and select the Connection Server you want to pair with.

2. Connection Servers Tab

3. Click on More Commands and select “Specify Security Server Pairing Password.”

3. Specify Security Server Pairing Password

4. Specify your pairing password.  When you do this, you will also be able to configure how long that password will be valid for.  If the password is not entered in that time period, or if you encounter errors with the install that are not resolved before the timeout period expires, you will need to create a new password.

4. Password Screen

Note: Pairing passwords can time out or be invalidated by hitting the back button during the Security Server installation after the pairing password has been entered.  If this happens, the password will need to be recreated using the steps above.

Installing the View Security Server

Once the pairing password is set up, you can start the Security Server installation.

1. Double-click the installer to start the installation.

2. Accept the license agreement


3. The next screen gives you the option to change the installation directory by clicking the Change button.  For this installation, we’ll be installing to the default location, so click Next.


4. Select Security Server


5. Enter the hostname or IP address of the Connection Server the Security Server will be paired with.


6. Enter the pairing password.


7. In order for View Clients to properly connect to the Security Server, you need to configure the External URLs for the server.  The items that need to be configured are:

  • External URL – the fully-qualified public domain name and port such as
  • PCoIP External URL – the public IP address and port number.  If this server is behind a NAT, this should be the IP address that can be reached from the Internet.  Example:
  • Blast External URL – the fully-qualified public domain name and port used by VMware Blast such as


8. The View Installer will give you the option to automatically configure the Windows Firewall for View.  Click Next to allow the installer to set up the Windows Firewall.  If you do not want the installer to configure the firewall, you will need to configure these rules manually after installation.

Note: This also configures the IPSec Rules that are needed for secure communication between the Security Server and the Connection Server.


9. Click Install to finish the installation.

10. Click Finish to close the installer.

11. If you log back into View Administrator and go to View Configuration –> Servers –> Security Servers, you should see your newly added Security Server.

14. Security Tab

Horizon View 6.0 Part 11–Creating A Desktop Pool #VDM30in30

Every system needs a way to group entities in order to organize them, delegate administration, and control security on them.  Horizon View uses desktop pools to group desktops, apply Horizon View specific policies, and entitle access to users. 

Horizon View has a few different types of desktop pools.  Each pool handles desktops in different ways, and they each have different purposes.  The type of pool that you select will be determined by a number of factors including the use case, the storage infrastructure and application requirements.

The type of desktop pools are:

  • Full Clone Pools – Each virtual desktop is a full virtual machine cloned from a template in vCenter.  The virtual machines are managed by View Connection Servers.
  • Linked Clone Pools – Each virtual desktop is based on a snapshot and shares its disk with the parent virtual machine.  Changes to the linked clone are written to a delta disk.  The virtual machines are managed by View Composer.
  • Manual Pools – The machines that make up the manual pool consist of virtual and/or physical machines that have had the View Agent installed.  These machines are not managed by View.
  • Terminal Services Pool – The machines that make up these pools are Windows Servers with the Remote Desktop Services Role installed.

There is one other choice that needs to be selected when creating a desktop pool, and that is the desktop assignment type.  There are two desktop assignment types:

  • Floating Assignment – Desktops are assigned to users at login and are returned to the pool of available desktops when the user signs out.
  • Dedicated Assignment – Desktops are assigned to a user, and the user gets the same desktop at each login.  Desktops can be assigned automatically at first login or manually by an administrator.

For this walkthrough, I will be doing an Automatic Assignment Linked-Clone desktop pool.  These pools are usually referred to as Non-Persistent Desktop Pools.

Before you can set up a Linked Clone pool, View Composer will need to be installed and configured.

1. Log into View Administrator.  Under Catalog, select Desktop Pools.


2.  Click Add to add a new pool.


3. Select the Pool Type that you want to create.  For this, we’ll select Automated Pool and click Next.


4.  Select whether you want to have Floating or Dedicated Desktops.  For this walkthrough, we’ll select Floating and click Next.


Note: The Enable Automatic Assignment option is only available if you select Dedicated. If this option is selected, View automatically assigns a desktop to a use when they log in to dedicated pool for the first time.

5. Choose the type of virtual machines that will be deployed in the environment. For this walkthrough, select View Composer Linked Clones and click Next.


6. Each desktop pool needs an ID and a Display Name.  The ID field is the official name of the pool, and it cannot contain any spaces.  The Display Name is the “friendly” name that users will see when they select a desktop pool to log into.  You can also add a description to the pool.


7. The next screen after setting the pool name is for the pool settings.  There are a lot of options here, that control how the pool will behave.  Some of the options are:

  • If the pool is enabled
  • Default power state of desktops
  • Display protocols
  • Adobe Flash settings




8. The next screen will allow you to configure the provisioning settings for the pool.  This screen allows you to control provisioning behavior, computer names, and the number of desktops provisioned in the pool.


9. The next screen allows you to set up a special non-persistent disk for disposable files.  Disposable files are classified as temporary files and page files.  If a disposable disk is used, these files will be redirected to here, and this disk is deleted whenever the VM is shut down.

This screen allows you to determine how the virtual desktop will handle these files.


10. Select the option to store Replicas on a separate datastore if you want to place them on a different storage tier.  Andre Leibovici has a good article on the benefits of placing Linked Clone replicas on a different datastore.


11. After you choose whether or not to place the Replica Disks on a separate datastore, you need to configure the pool’s vCenter settings.  This covers the Parent VM and the snapshot that the Linked Clones will be based on, the folder that they will be stored in within vCenter, and the cluster and datastores that will be used.

In order to configure each setting, you will need to click the Browse button on the right hand side of the screen.  Each step must be configured in order.


11-A. The first item that needs to be configured is the Parent VM that the Linked Clones will be based on.  Select the VM that you want to use and click OK.


11-B. The next step is to select the Parent VM snapshot that the Linked Clones will be based on.  Select the snapshot that you want to use and click OK.


11-C. After you have selected a Parent VM and a snapshot, you need to configure the vCenter folder in the VMs and Templates view that the VMs will be placed in.  Select the folder and click OK.


11-D. The next step is to place the pool on a vSphere cluster.  The virtual machines that make up the desktop pool will be run on this cluster, and the remaining choices will be based on this selection.  Select the cluster that they should be run on and click OK.


11-E. The next step is to place the desktops into a Resource Pool.  In this example, I have not resource pools configured, so the desktops would be placed in the Cluster Root.


11-F. The final two steps of this section are to select the datastores where the Linked Clones and the Replicas will be stored.  Linked Clones can be stored on multiple datastores, so you can select multiple datastores in this section.  You can also configure View to allow the datastores to be overcommitted by changing the Storage Overcommit option on each datastore.


11-G. Replicas can only be stored on a single datastore.  Select the datastore that you want to store them on and click OK.


Note: After you have configured the Replica Datastore, you may receive the following warning about storing Replicas and Linked Clones on local datastores.  If you are using a SAN or a NAS and not storing any Replicas or Linked Clones on local datastores, you can ignore this message.

Warning after 18-19

12. The next screen is for configuring the advanced storage options.  The three options that can be configured on this screen are the View Storage Accelerator, disk space reclaimation and the option to use native NFS snapshots.

If you use View Storage Accelerator or disk space reclamation, you can configure blackout times where vCenter will not run these tasks.


13. To set the blackout times for the pool, click the Add Button and select the days and times when you do not want these operations to run.  You can set multiple schedules.


14. After you have configured the advanced storage options, you need to configure the Guest Customization settings.  This screen allows you to select the domain and organizational unit for the desktops and whether Sysprep or Quickprep will be used to prepare the desktops.


15. Review the settings for the pool and verify that everything is correct.  Before you click Finish, check the Entitle Users checkbox in the upper right.  This will allow you to select the users and/or groups who have permission to log into the desktops.

If you need to make a change to the pool settings, the left-hand column contains links to each page in the wizard.


17. After you click Finish, you will need to grant access to the pool.  View allows you to entitle Active Directory users and groups.  Click Add to entitle users and groups.


18. Search for the user or group that you want to add to entitle.  If you are in a multi-domain environment, you can change domains by selecting the domain from the Domains box.  Click on the users or groups that you want to grant access to and click OK.


Note:  I recommend that you create Active Directory security groups and entitle those to desktop pools.  This makes it easier to manage a user’s pool assignments without having to log into View Administrator whenever you want to make a change.

19. You can check the status of your desktop pool creation in vCenter.  If this is a new pool, it will need to clone the VM into a Replica before it can create the Linked Clone desktops. 


Once the desktops have finished composing, you will be able to log into them through VMware Blast or the Horizon View client. 

I realize that there are a lot of steps in the process of creating a desktop pool.  It doesn’t take nearly as long as it seems once you get the hang of it, and you will be able to fly through it pretty quickly.  These steps can also be automated using the View PowerCLI cmdlets from any Connection Broker in the environment.