Implementing VMware Horizon 7 - Second Edition

VMware Horizon Connection Server is a software service that serves as the broker for Horizon client connections. In this role, it authenticates user connection requests, verifies the desktops or Microsoft Windows RDS Servers that the user is entitled to access, and then directs the connection to the appropriate resource. Horizon Connection Server is installed on a dedicated server that is required to be a member of an Active Directory (AD) domain that is trusted by all Horizon clients. Horizon Connection Server also hosts the Horizon Administrator console, an Adobe Flex-based web application that is used to manage the Horizon environment and perform tasks, such as:

The Horizon Connection Server is one component that is required in every Horizon environment owing to the role it plays as the connection broker and management console. Chapter 2, Implementing Horizon Connection Server, provides the information needed to install and configure a VMware Horizon Connection Server. Chapter 6, Implementing a Horizon Cloud Pod, provides information about the configuration of the Cloud Pod feature that is used to provide Horizon clients access to desktops across multiple Horizon Pods, each Pod representing a standalone installation of VMware Horizon. The following chapters provide information about the deployment of Horizon desktops and management of desktop pools:

VMware Horizon Security Server is a custom instance of the Horizon Connection Server that is designed to be installed in a datacenter demilitarized zone (DMZ), to provide strong authentication and secure access for Horizon clients connecting from outside the organization's private network. Multiple Security Servers may be installed to provide load balancing and high availability to these external clients. The following figure shows the placement of a Horizon Security Server, or Access Point (described next), within a DMZ.

Horizon Security Server is installed on top of a supported version of Microsoft Windows' Server using the same installation package used for Horizon Connection Servers. Horizon Security Server is only required if providing access to Horizon clients residing outside of the company network. Chapter 4, Implementing Horizon Security Server, provides the information needed to install and configure a VMware Horizon Security Server.

VMware Horizon Access Point was first introduced in VMware Horizon 6.2, although it was previously used with the VMware Horizon Air cloud-hosted desktop and application offering. Like Horizon Security Server, Access Point is designed to provide strong authentication, and secure access, for Horizon clients connecting from outside the organizations private network. The figure in the previous section shows the placement of a Horizon Access Point within a DMZ environment, as is typical, since it performs similar functions to Horizon Security Server.

Access Point is packaged in Open Virtualization Format (OVF) and is deployed on vSphere as a hardened, pre-configured Linux-based virtual appliance. Horizon Access Point is provided as an option on Horizon Security Server, and like Security Server, it is only required if providing access for external clients, it is designed to be installed in a DMZ, and multiple appliances may be installed to ensure high availability and load balancing. Chapter 5, Implementing VMware Horizon Access Point, provides the information needed to install and configure a VMware Horizon Access Point.

VMware Horizon Enrollment Server is new to version 7, is installed as a standalone service and integrates with VMware Identity Manager to enable true Single Sign-On (SSO) for Horizon clients that are using non-AD-based authentication methods such as RSA SecureID. SSO means that, when using non-AD-based authentication methods, users will only need to log into Horizon once to reach their desktop or streamed application. The VMware blog post Introducing True SSO (Single Sign-On) in VMware Horizon 7 (http://blogs.vmware.com/euc/2016/03/true-sso-single-sign-on-view-identity-manager-authenticate.html) provides an overview of this new Horizon feature.

This feature is only used when Horizon clients use non-AD-based methods for authentication. Implementing solutions, such as SecureID and VMware Identity Manager, is outside the scope of this book, which is why the Enrollment Server will not be covered. Consult the Horizon documentation (https://www.vmware.com/support/pubs/view_pubs.html) for additional information about the deployment and configuration of Horizon Enrollment Server.

VMware vSphere, also referred to as ESXi or even ESX for earlier versions, is a Type 1 hypervisor that is the virtualization platform used for the vSphere suite of products. Type 1 hypervisors are designed to run directly on the host hardware, whereas Type 2 hypervisors run within a conventional operating system environment.

ESXi is the only hypervisor that is fully supported by VMware for hosting Horizon virtual desktops, as it fully integrates with Horizon for full desktop lifecycle management. All of the primary desktop provisioning and maintenance tasks are performed using the Horizon Administrator console; the vSphere Client is not used. Horizon supports multiple versions of vSphere, but vSphere 6.0 Update 1 and newer are required to leverage many of the latest features of the platform, and vSphere 6.0 Update 2 is required when you want to use the latest version of Virtual SAN (VSAN). Refer to the VMware vCenter Server requirements section for examples of some Horizon features that require a specific version of both vSphere and vCenter Server.

VMware vSphere also includes the VSAN feature that uses local ESXi server storage to build a highly resilient virtual storage area network (SAN) to provide storage for virtual machines. VMware Horizon supports using VSAN, and we will review how to do so in Chapter 7, Using VMware Virtual SAN with Horizon.

VMware vCenter Server is a software service that provides a central administration point for VMware ESXi servers as well as other components of the vSphere suite. vCenter Server performs the actual creation and management of virtual desktops, based on instructions received from the Horizon Connection Server and the Horizon Composer Server.

VMware Horizon Composer is a software service that works alongside the VMware vCenter and Horizon Connection Servers to deploy and manage linked clone desktops. Horizon Composer can be installed directly on the vCenter Server, or on a dedicated server.

Horizon Composer is only required if linked clone desktops will be deployed. Chapter 3, Implementing Horizon Composer, provides the information needed to install and configure Horizon Composer.

VMware Horizon Agent is a software service that is installed on the systems that will be managed by Horizon. This includes not only a virtual desktop image that will be deployed using Horizon, but any physical desktops or Microsoft RDS Servers as well.

The Horizon agent provides services including, but not limited to, support for connecting the virtual desktop to Horizon's client-attached USB devices, client connection monitoring, Virtual Printing, and single sign-on.

VMware Horizon Client is a software application that is used to communicate with a Horizon Connection Server, and initiate connections to desktops and Microsoft Windows RDS servers.

The Horizon Client is available for multiple software platforms, including Microsoft Windows, Apple OSX and IOS, Android, and Ubuntu Linux. In addition, there are a number of Thin and Zero clients that come preloaded with Horizon-compatible clients.

VMware App Volumes is an optional component of VMware Horizon that provides multiple capabilities, particularly in environments where floating assignment desktops are used or changes to a virtual desktop are discarded after every session (also known as non-persistent desktops). The deployment and configuration of VMware App Volumes is discussed in detail in Chapter 9, Implementing VMware App Volumes.

The primary features of VMware App Volumes include:

The following diagram shows the logical layering of multiple AppStack and a Writeable Volume on top of the host operating system. Each of the items is attached to the host virtual machine individually when a user logs in, can be removed individually if changes are required, and will follow a user from one login to the next.

App Volumes AppStacks are packaged as a Virtual Machine Disk (VMDK) file and attached to one or more virtual machines as needed. The App Volumes agent seamlessly integrates this VMDK into the virtual machines OS; no actual installation is performed. AppVolumes can even capture an application packaged using VMware ThinApp, which provides organizations who rely on ThinApp with an additional method for distributing its virtualized application packages.

App Volumes creates a unique Writeable Volume for each user, using a VMDK that is also seamlessly integrated into their current virtual machine. The Writable Volumes is attached to the Horizon desktop when the user logs in, and detached upon logoff.

The combination of VMware App Volumes, and VMware User Environment Manager (discussed next), provides organizations with a way to leverage the efficiencies of floating assignment non-persistent desktops (described in Chapter 10, Creating Horizon Desktop Pools), while still providing users a highly personalized desktop experience.

VMware User Environment Manager (UEM) is an optional component of VMware Horizon that provides the ability to roam end user Windows profile and persona configuration data, including application settings, across different Windows operating system (OS) versions, or even between physical desktops and virtual desktops or Windows RDS servers.

VMware UEM works with all three Microsoft Windows profile types, including mandatory, roaming, or local. UEM is not a replacement for any of these profile types as it does not roam user data across sessions or devices, only the profile and persona configuration. User data should be saved using techniques such as roaming profiles, or even folder redirection.

Highlights of the benefits of UEM include:

Chapter 8, Implementing VMware User Environment Manager, provides information about how to implement and administer UEM.

VMware ThinApp is an application virtualization platform that integrates with Horizon to provide users with rapid access to new or upgraded applications without having to perform any changes to the virtual desktops. Applications that have been packaged with ThinApp are delivered as a single executable file that runs in complete isolation to both of the other ThinApp packaged applications, as well as applications that are installed on the desktop itself.

ThinApp provides Horizon customers with a number of powerful capabilities. The following list details two popular scenarios where ThinApp can benefit an organization:

This book does not have a dedicated chapter concerning VMware ThinApp; consult the VMware ThinApp documentation page for details about how it is used (https://www.vmware.com/support/pubs/thinapp_pubs.html).

VMware Horizon requires Microsoft Active Directory to support the virtual desktop infrastructure. VMware Horizon supports all AD domain functional levels starting with Windows 2003 and up to Windows 2012 R2.

Horizon also requires Domain Name System (DNS) servers that can resolve requests for the standard Microsoft Active Directory Service Record (SRV) and Resource Record (RR) DNS entries. Microsoft domain-integrated DNS servers typically store these DNS entries by default. Incomplete or inaccurate DNS entries can lead to issues with tasks, such as virtual desktop deployment and user authentication.

Dynamic Host Configuration Protocol (DHCP) servers are required in the Horizon environment to provide Internet Protocol (IP) addresses to the virtual desktops. In situations where the virtual desktops cannot self-register the IP addresses they have been assigned, the DHCP server should be configured to register the entries with a DNS server that is accessible by the Horizon Connection Server.

The following table shows which 64-bit, non-Core Microsoft Windows Server OSs are supported for the each of the different software packages that comprise a Horizon infrastructure. App Volumes host OS requirements will be outlined separately in Chapter 9, Implementing VMware App Volumes.

While VMware vCenter and the different Horizon servers support a number of different Windows OSs, it is recommended to use the newest supported version to ensure that the servers will not be impacted by any changes in OS support by Microsoft. Additionally, you never know when vSphere or Horizon itself will end support for older OSs, which would impact your ability to perform in-place upgrades.

As Horizon Composer supports only Windows Server 2008 R2 SP1 or 2012 R2, any Horizon installation that plans on deploying linked clone desktops, and installing Composer directly on the vCenter Server, will need to choose that specific version of Windows. Refer to the VMware document View Installation (http://www.vmware.com/support/pubs/view_pubs.html) for updated information about which Windows OSs are supported.

The following list shows which database types are supported for the core components of a Horizon infrastructure, which includes the Horizon Connection Server, Horizon Composer, and vCenter Server. Unless otherwise noted, both 32-bit and 64-bit versions of the specified database platform are supported. Database platforms that support some, but not all, of the components will not be listed. App Volumes database requirements will be outlined separately in Chapter 9, Implementing VMware App Volumes.

For VMware Horizon, visit the product installation guide (http://www.vmware.com/support/pubs/view_pubs.html) for updated information on which databases are supported. For VMware vCenter, refer to the Product Interoperability Matrix (http://www.vmware.com/resources/compatibility/sim/interop_matrix.php) for updated information, or to quickly verify if the databases listed in the Horizon documentation are also supported by vCenter.

VMware Horizon supports multiple versions of vSphere. The purchase of Horizon licenses entitles users to use the latest supported version of both vSphere and vCenter Servers, although support is maintained for some older versions due to restrictions that some organizations may be under.

The following versions of vSphere are supported by VMware Horizon:

Consult the VMware Product Interoperability Matrix for an updated list of the supported versions of vSphere and vCenter Servers. Supporting earlier versions of vSphere and vCenter Servers is important for customers who are already running earlier versions of either software platform, and cannot, or will not, upgrade for some reason. Even with this support, it is recommended to use dedicated ESXi servers and vCenter Servers for your Horizon environment to ensure that all the latest Horizon features are supported.

There are multiple Horizon features that are supported only if certain other prerequisites are met. Some examples of these vSphere version dependent features are:

A complete list of Horizon features that require specific versions of vSphere or vCenter Server may be found in VMware document View Installation (http://www.vmware.com/support/pubs/view_pubs.html) or the View Release Notes (http://pubs.vmware.com/Release_Notes/en/horizon-7-view/horizon-70-view-release-notes.html) that accompany each release of the Horizon platform.

The VMware Horizon Agent supports multiple versions of the Microsoft Windows desktop operating system and Microsoft Windows (RDS) Server. The following table outlines which Windows OSs are currently supported.

To obtain current information about which desktop operating systems and Microsoft RDS servers are supported, please refer to the online VMware Product Interoperability Matrix.

One of the most important aspects of any Horizon design is ensuring that an infrastructure has adequate compute, storage, and network resources to host the required number of virtual desktops. Were it not for troublesome things such as budgets, we could simply purchase an excess of all three of those resources and rest easy at night. In general, our goal is to build an infrastructure that is robust enough to support our average user workload, with some capacity in reserve for growth or maintenance purposes.

Determining the resource requirements of a Horizon environment is a complicated task, and one that could, by itself, fill a book. While it is possible to collect desktop performance data using free tools such as Windows Performance Monitor, gathering all of the data you need would be difficult, and interpreting it even more so. The goal in this section is to introduce you to some tools that were created specifically to help in designing and testing virtual desktop infrastructures, so that you understand exactly what is required to ensure a successful implementation.

The following products can assist in determining your resource requirements and ensuring that your vSphere infrastructure has sufficient capacity and the performance capabilities needed to ensure the desktops perform as expected.

It is important to note that these software packages are typically used as part of a virtual desktop assessment project led by an outside vendor. If your user base has varying requirements, products such as SysTrack and Statusphere FIT may be the only way to find out exactly what infrastructure resources you need to ensure a successful VMware Horizon deployment.

In the event that you choose to determine your own vSphere infrastructure requirements, it is very important to keep in mind the concept of vSphere reserve capacity. I realize that you may choose to do maintenance after hours, so reserve capacity may not be a priority, but what about unplanned downtime, or periods where you can't do maintenance after hours? Many users simply cannot work if they do not have access to their computer, and now that you have virtualized that computer it is your job to ensure it is available whenever it is needed.

Maintaining reserve ESXi server capacity is critical to ensuring that we can accommodate all of our desktops in the event of an ESXi server failure or host maintenance operation. Consider a vSphere cluster with eight ESXi servers hosting 128 desktops each (1024 total desktops):

These calculations assume that we want to protect the ability to provide resources for 100 percent of our desktops at all times, which is a very conservative yet valid approach to building a Horizon infrastructure.

The final configuration of the ESXi servers should take into account not only what percentage of desktops are actually in use at a given time, but also the cost of purchasing the additional capacity needed to support ESXi server failures or other events that require downtime.

In the era of affordable 10 Gigabit Ethernet (GbE) for servers and 1 GbE for desktops I realize that bandwidth within a single site is typically not a concern. The following information is something to keep in mind for clients who are connecting to their Horizon desktop remotely, either from over the Internet or over a WAN from another company site. Ensuring that sufficient bandwidth is available is just another part of making sure your Horizon clients have an acceptable experience when connecting to the Horizon infrastructure.

The VMware document View Architecture Planning (http://www.vmware.com/support/pubs/view_pubs.html) provides some information about how to determine Horizon Client bandwidth requirements. The following table is built upon information obtained from that document as well as other VMware documentation:

Bandwidth utilization is heavily dependent on a number of factors, many of which can be controlled with the Horizon PCoIP GPO settings or even Windows OS settings. Actual bandwidth utilization will vary based on usage and PCoIP settings.

Even with a careful analysis of user desktop usage patterns, it is important to remember that there will be spikes in usage from time to time. A Knowledge or Task Worker who has a need to use an application with a large amount of screen changes, such as viewing images in succession or watching a video, may cause a brief bandwidth spike of between 500 Kbps and 1 Mbps or more. Preparing for these spikes in bandwidth utilization is important in order to preserve the quality of service for all of the Horizon Client connections.

Refer to Chapter 13, Creating a Master Horizon Desktop Image, for information about optimal settings for a Windows desktop, an important topic for those new to virtualizing desktops. Chapter 15, Using Horizon PowerCLI, provides useful information for individuals who prefer to use scripts to automate as many tasks as possible, or simply to try and integrate Horizon with existing infrastructure management platforms.

Up until now, this chapter has been about introducing us to a variety of different concepts that form the basis of architecting our Horizon infrastructure. If we learn anything from this chapter, it is that our goal is to obtain the resources we need to provide an acceptable end user computing experience.

Classifying our end users and measuring their resource requirements is a valuable exercise that will help us understand what will be required to transition our end user computing resources from the desktop to the datacenter. That being said, no amount of planning can possibly replace a properly run pilot that validates not only the configuration of our master Virtual Desktop image, but also the performance of the Horizon infrastructure and the quality of the experience from an end user perspective.

Our Horizon pilot should involve the same types of users as our user analysis did, but not necessarily the same users within each group. The following list includes a number of goals that our Horizon pilot should attempt to achieve: