This chapter will discuss a number of topics that play a critical role in our Horizon design. We will discuss the different components of a Horizon installation, examine the different license levels, and outline the core requirements of a Horizon infrastructure. We will also consider how to measure the resource requirements of a desktop, and how those requirements impact all layers of our infrastructure, including the storage design, network design, and the configuration of our virtual desktop VMware vSphere hosts.

By the end of this chapter, we will have learned about the following:

• The individual components of a VMware Horizon installation
• The role of different components of VMware Horizon
• VMware Horizon license options
• Core infrastructure requirements for VMware Horizon
• An overview of several key VMware Horizon design and pilot project considerations

VMware Horizon is a family of desktop and application virtualization solutions designed to deliver end user computing services, from both on-premises data centers and from cloud providers such as Amazon Web Services (AWS). The following section will provide a high-level overview of the components in the Horizon family of products that we will cover in this book, which includes the following:

• VMware Horizon Connection Server, Security Server, and Unified Access Gateway
• VMware Horizon Help Desk Tool
• VMware Horizon Just-in-Time Management Platform (JMP)
• VMware Horizon Composer
• VMware Horizon Agent
• VMware Horizon Client
• VMware vSphere, including vCenter Server
• VMware App Volumes
• VMware User Environment Manager
• VMware Horizon PowerCLI

The following diagram shows where each component of a typical Horizon installation resides within the data center. The only components that are not shown but are discussed in this book are the VMware App Volumes servers and the Windows-based files servers used for hosting VMware User Environment Manager data. If they were to be shown, both of these components would be located on the internal network, along with the Horizon Connection Server, vCenter Server, virtual desktops, and Microsoft Windows Remote Desktop Session (RDS) servers.

VMware Horizon Connection Server is a software service that performs 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 including the following:

• Deploying virtual desktops
• Creating desktop or Microsoft Windows RDS-based pools
• Controlling access to desktop pools
• Creating and managing Horizon Cloud Pods
• Examining Horizon system events

The Horizon Connection Server is one component that is required in every Horizon environment. 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 regarding the configuration of the Cloud Pod feature that is used to provide Horizon clients with access to desktops across multiple Horizon Pods, with each Pod representing a standalone installation of VMware Horizon. The following chapters provide information about the deployment of Horizon desktops and the management of desktop pools:

• Chapter 7, Creating Horizon Desktop Pools
• Chapter 8, Implementing Microsoft Remote Desktop Services Application and Desktop Pools
• Chapter 9, Performing Horizon Pool Maintenance

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), in order to provide strong levels of 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 diagram shows the placement of a Horizon Security Server or Unified Access Gateway (discussed 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 Unified Access Gateway, previously known as Horizon Access Point and first introduced in VMware Horizon 6.2, is designed to provide strong authentication, and secure access, for Horizon clients connecting from outside the organization's private network. The diagram in the previous section shows the placement of a Horizon Unified Access Gateway within a DMZ environment, as is typical since it performs similar functions to Horizon Security Server.

Unified Access Gateway is packaged in Open Virtualization Format (OVF) and is deployed on vSphere as a hardened, pre-configured Linux-based virtual appliance. Horizon Unified Access Gateway is provided as an option to 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 Horizon Unified Access Gateway, provides the information needed to install and configure a VMware Horizon Unified Access Gateway.

The VMware Horizon Enrollment Server was first introduced in version 7, is installed as a standalone service, and integrates with the VMware Workspace ONE 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 the VMware Workspace ONE Identity Manager, is outside of our scope. Therefore, the Enrollment Server will not be covered here, so consult the Horizon documentation (https://docs.vmware.com/en/VMware-Horizon-7/index.html) for additional information about the deployment and configuration of the 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 OS 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 life cycle 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. vSphere 6.0 Update 2 or newer is required 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. The deployment and configuration of vSAN are outside of our scope, so consult the Horizon documentation (https://docs.vmware.com/en/VMware-Horizon-7/index.html) if you require information about using vSAN 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 required 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 also any physical desktops or Microsoft RDS Servers.

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 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 are discussed in detail in Chapter 11, Implementing App Volumes.

The primary features of VMware App Volumes include the following:

• The ability for applications to be delivered to Horizon desktops or Microsoft Windows RDS servers, immediately and dynamically, in a manner that is transparent to the end user. This feature works both with Horizon desktops and Microsoft Windows RDS servers, and is called an App Volumes AppStack.
• The ability to roam user-installed applications across Horizon client sessions, even if a different desktop virtual machine is assigned during the next login. This feature is designed for use with Horizon desktops only, and is called Writable Volumes.

The following diagram shows the logical layering of multiple AppStack and a Writeable Volume on top of the host OS. 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 machine's OS so 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 when the user logs off.

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 7, Creating Horizon Desktop Pools), while still providing users with 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 across 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 the following:

• A consistent and personalized end user experience, regardless of where a user logs in or which Windows OS they are using
• Implementation of various settings that previously required AD group policies, such as Windows user profile redirection, and some Horizon agent settings
• Customization of user settings, such as printers, based on logon location
• Elimination of the need to perform user profile migrations when moving to a newer version of Windows that has a new profile type (such as from Windows 8.1 to Windows 10)
• Robust design that scales to support over a hundred thousand end users
• Simple design that requires no scripting knowledge, can be implemented rapidly, and requires minimal infrastructure to begin using

Chapter 12, Implementing User Environment Manager, provides information regarding the implementation and administration of 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. Two popular scenarios where ThinApp can benefit an organization are as follows:

• It eliminates application conflicts that can occur when specific programs are installed together within the desktop image
• It virtualizes legacy applications to ensure that they will continue to function regardless of the underlying Windows OS

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

VMware Horizon offers four different license levels: Standard, Linux, Advanced, and Enterprise. Additionally, the Advanced and Enterprise licenses may be purchased as Named User (NU) or Concurrent Connection User (CCU) as needed. Named user licenses are recommended when your staff needs dedicated access to Horizon; concurrent connection user licenses are recommended when access to Horizon will be shared among many users, but only a portion of them will be connected at any one time.

The license levels are differentiated by several factors, as outlined in the following section. The licenses themselves are sold in packs of 10 or 100:

• All VMware Horizon license levels include VMware Horizon, vCenter, and vSphere Desktop Edition:
  • vSphere Desktop Edition is similar to vSphere Enterprise Plus in terms of functionality, but allows an unlimited number of CPU sockets for the desktop ESXi servers.
• VMware ThinApp is included with all versions, except the Linux edition
• Standard and Linux offer similar features, the only difference is the desktop OS that they are licensed for:
  • Horizon Enterprise edition supports both Windows and Linux desktop OSes under the same license
• Advanced and Enterprise includes licenses for Fusion Pro, Workspace ONE Identity Manager, application publishing using Windows RDSH servers, VMware Virtual SAN Advanced, and Virtualization pack for Skype for Business.
• Enterprise includes licenses for Horizon Instant Clones, Horizon Help Desk Tool, VMware App Volumes Enterprise, User Environment Manager, vRealize Operations for Horizon, and the vRealize Orchestrator Plugin for VMware Horizon.

Visit the VMware Horizon website (https://www.vmware.com/products/horizon.html) for the most recent information concerning licensing options and their costs.

When listing the different components included with each VMware Horizon license level, you may have noticed that not all of them will be discussed in this book. The primary focus of this book is on VMware Horizon View itself, and those components of VMware Horizon that are most commonly used to extend its capabilities and potential use cases. For more information regarding those components, consult the following VMware resources:

• VMware Fusion (https://www.vmware.com/products/fusion.html)
• VMware Horizon Cloud (https://www.vmware.com/products/horizon-cloud-virtual-desktops.html)
• VMware Workspace ONE Identity Manager (https://www.vmware.com/products/workspace-one/identity-manager.html)
• VMware ThinApp (https://www.vmware.com/products/thinapp.html)
• VMware vRealize Orchestrator Plugin for VMware Horizon (https://docs.vmware.com/en/VMware-Horizon-7/7.6/using-horizon-vro-plugin/GUID-90269DBE-7760-4FF7-9F7D-E42F19A2270C.html)
• VMware vRealize Operations for Horizon (https://www.vmware.com/products/vrealize-operations-horizon.html)

There are a number of requirements to contemplate even before the infrastructure needs of the virtual desktops themselves are considered. These include, but are not limited to, the following:

• OS requirements for both vSphere and Horizon components
• Database requirements for vCenter Server, Horizon Composer, and Horizon Connection Server
• Required Microsoft infrastructure services and components

VMware Horizon requires Microsoft AD to support the virtual desktop infrastructure. VMware Horizon supports all AD domain functional levels, starting with Windows 2003 up to Windows 2016.

Horizon also requires Domain Name System (DNS) servers that can resolve requests for the standard Service Record (SRV) and Resource Record (RR) DNS entries. 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 that 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 OSes 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 11, Implementing App Volumes:

While VMware vCenter and the different Horizon servers support a number of different Windows OSes, use of the newest supported version is recommended 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 OSes, which would impact your ability to perform in-place upgrades.

As Horizon Composer supports only Windows Server 2008 R2 SP1, 2012 R2, and 2016, 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 Horizon 7 Installation (https://docs.vmware.com/en/VMware-Horizon-7/index.html) for updated information regarding which Windows OSes 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 and Horizon Composer. 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 11, Implementing App Volumes. The databases are as follows:

• Microsoft SQL Server 2017 (Standard and Enterprise; 64-bit is the only version available)
• Microsoft SQL Server 2016 (Standard and Enterprise; through SP1 and 64-bit only)
• Microsoft SQL Server 2014 (Standard and Enterprise; SP1)
• Microsoft SQL Server 2012 (Express, Standard, and Enterprise; 64-bit and SP3 only)
• Microsoft SQL Server 2008 R2 (Express, Standard, and 64-bit Enterprise; SP3)
• Oracle 12C Standard Edition, Release 2 (12.2.0.1.0) - 64-bit

For VMware Horizon, visit the product installation guide (https://docs.vmware.com/en/VMware-Horizon-7/index.html) for updated information regarding which databases are supported.

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:

• vSphere 6.7.0
• vSphere 6.5.0, 6.5 U1, or 6.5 U2
• vSphere 6.0 (Update 1 or newer is required to support the latest Horizon features; Update 2 or newer is required to support VSAN 6.2)
• vSphere 5.5 (Update 3b or newer recommended; SSLv3 must be re-enabled as described in VMware KB article 2139396) (https://kb.vmware.com/s/article/2139396)

Consult the VMware Product Interoperability Matrices 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, the use of dedicated ESXi servers and vCenter Servers for your Horizon environment is recommended 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. Examples of these vSphere version-dependent features include the following:

• vSphere 6 is required to use VMware vSAN, or Windows 10 as a desktop OS
• Prior to vSphere 6, the vCenter Server Appliance could not support the maximum number of desktops that can be deployed in a single Horizon Pod
• Some virtual desktop graphics acceleration technologies, such as NVDIA GRID Tesla processor-based server cards (https://www.nvidia.com/en-us/design-visualization/technologies/virtual-gpu/), require vSphere 6 or newer.

A complete list of Horizon features that require specific versions of vSphere or vCenter Server may be found in VMware document Horizon 7 Installation (https://docs.vmware.com/en/VMware-Horizon-7/index.html) or the Horizon 7 Release Notes (https://docs.vmware.com/en/VMware-Horizon-7/7.6/rn/horizon-76-view-release-notes.html) that accompany each release of the Horizon platform.

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

To obtain current information about which desktop OSes and Microsoft RDS server versions are supported, please refer to VMware KB articles 2149393 (https://kb.vmware.com/s/article/2149393), 2150305 (https://kb.vmware.com/s/article/2150305), and 2150295 (https://kb.vmware.com/s/article/2150295).

The primary focus of this book is to show you how to deploy and configure VMware Horizon. Ultimately, the deployment is only one part of a successful Horizon implementation. Determining the infrastructure requirements of your virtual desktops is critical to ensuring that all your hard work implementing Horizon won't ultimately be a disappointment because you failed to consider what your desktops actually need.

Some organizations that are virtualizing older desktops that lack flash drives, may feel that meeting their users' needs will be easy because expectations are low from the start. Of course, some organizations tend to forget that their users are probably using flash-based devices at home. This means that even with a poor computing experience at work, these users will have some expectation of what it is like when they get a new computer, which is what their new Horizon desktop will appear to be. So, even if your Horizon infrastructure is capable of providing performance that is similar to the computers that users have today, that does not mean it will provide an experience that the users will find acceptable.

The goal of this section is to provide some information that you need to consider before you buy your Horizon licenses. Buying those licenses is the easy part, assembling the infrastructure they will be built on, is not. Unfortunately, it isn't possible to put into words everything you need to know in order to build an infrastructure that guarantees a good performance for your users. Therefore, I have suggested a detailed analysis of the network and storage infrastructure that you intend to use with your Horizon infrastructure. This analysis, combined with an understanding of the resources your Horizon infrastructure will require, is integral to delivering a superior end user experience.

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 fill a book by itself. 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 is even harder.

The goal in this section is to introduce you to some tools that were created specifically to help with 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. These are as follows:

• Lakeside Software SysTrack (https://www.lakesidesoftware.com/solutions/desktop-transformation) performs an extensive analysis of your existing desktop workloads, including characterizing those that would be difficult to virtualize, and helps determine infrastructure needs and optimal placement.
• Liquidware Labs Stratusphere UX (http://www.liquidware.com/products/stratusphere-UX) can assist you in determining virtual desktop resource needs and performs tasks similar to Lakeside Software SysTrack.
• Login VSI (http://www.loginvsi.com/) has created tools that can be used to test the performance of your Horizon infrastructure. Login VSI is used to run a simulated user workload in as many desktops as you want to test the performance of all layers of your virtual desktop infrastructure.

It is important to note that these software packages are typically used as part of a virtual desktop assessment project led by an outside system integrator. If your user base has varying requirements, products such as SysTrack and Statusphere UX 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 (1,024 total desktops):

• Desktop requirements:

• • Each single vCPU desktop requires 10 percent of one ESXi server CPU core
  • Each desktop requires 2,048 MB of memory
• Eight ESXi servers, each running 12.5 percent of the total number of virtual desktops:
  • 1,024 desktops / 8 ESXi servers = 128 desktops per host
• To continue to run all of the desktops in the event one of the ESXi servers was to become unavailable; we would need to be able to accommodate 18.29 desktops on each of the remaining seven hosts:
  • 128 desktops / 7 remaining vSphere hosts = 18.29 desktops per each ESXi server
• To continue to run all desktops without any degradation in the quality of service; each server needs to have an excess of capacity that is sufficient to host 18 to 19 desktops. This is entails the following:
  • 19 desktops * 10% of a CPU core = 1.9 available CPU cores required
  • 19 desktops * 2,048 MB of memory = 38,912 MB or 38 GB of available memory required
  • 19 desktops * 121.21 MB of memory for virtual machine overhead = 2,303 MB or 2.3 GB of additional available memory required
  • 19 desktops * 0.75 MB network bandwidth = 14.25 MB of available network bandwidth required
  • 19 desktops * 0.23 MB storage network bandwidth = 4.37 MB of available storage network bandwidth required

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 Horizon 7 Architecture Planning (https://docs.vmware.com/en/VMware-Horizon-7/index.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 and Blast GPO settings. Additionally, Windows OS settings, such as display resolution and quality, can also affect bandwidth utilization. Actual bandwidth utilization will vary based on the client usage pattern, the protocol being used, and your GPO 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 Worker or Task Worker who has a need to use an application with a large number 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 10, Creating a Master Horizon Desktop Image, for information regarding optimal settings for a Windows desktop, an important topic for those new to virtualizing desktops.

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 data center. 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:

• Include multiple users from each user classification: Task Worker, Knowledge Worker, and Power User
• Include fully remote users, as well as WAN-connected users at other company sites
• Perform additional performance analysis at all layers of the Horizon infrastructure, including:
  • Storage
  • Network
  • ESXi server
  • Guest operating
• Measure the impact of common Horizon scenarios, such as:
  • User logon storms: Large numbers of users logging on within a short time frame
  • Steady-state user load: Measure Horizon infrastructure performance during a period of steady desktop usage by a significant number of users
  • Antivirus platform performance: Measure the impact of common antivirus platform tasks, such as on-demand scans and pattern file updates
  • Horizon refresh or recompose: Measure the impact of these common Horizon linked-clone desktop maintenance operations, described in detail in Chapter 9, Performing Horizon Desktop Pool Maintenance
  • A fully populated ESXi server: Measure host performance with higher than normal workloads, such as simulating an outage or another period of higher than usual utilization.

Performance deficiencies at any layer of the Horizon infrastructure can lead to a poor end user experience, usually in the form of longer than anticipated application response times. This is why it is critical to involve a large cross-section of our users in the pilot process, and to seek their opinion throughout the program.

The performance data that we collect during the pilot program can be used to measure the average of the actual resource utilization, which can then be compared to the estimated average resource utilization from the initial physical desktop analysis. Ideally, the numbers would be rather close to one another, but if they are not, we will want to work to identify the cause. Now that we can measure performance at all layers of the Horizon infrastructure, it should be easy to determine where the higher than expected utilization originates from. Some potential issues to look for include the following:

• The earlier analysis of the users did not include a sufficient number or a wide enough cross-section of users.
• The Virtual Desktop master image was not properly optimized. Refer to Chapter 10, Creating a Master Horizon Desktop Image, for details on how to optimize the master desktop image.
• A component of the Horizon infrastructure was improperly configured. This problem can affect any number of components of the infrastructure.
• The pilot program is occurring during a period of higher than normal user workload, for example, a recurring event unique to the organization, such as financial reporting.

In summary, the Horizon pilot is your best time to learn about how it will perform within your environment, both from a performance perspective and in terms of user acceptance. Use the pilot program to identify any potential barriers to a successful rollout, and make any changes that are needed in order to minimize the risk of failure as the project moves forward.

In this chapter, we have been introduced to the different components that comprise a VMware Horizon infrastructure, including the licensing and core infrastructure requirements. Later chapters will discuss how to install and configure each of these components.

We have also been introduced to the basics of what level of research is required even before the first virtual desktop is deployed, including assessing our existing physical desktops, determining bandwidth requirements for remote users, and adjusting our design to accommodate ESXi server maintenance or failure.

We concluded this chapter by learning the basics of running a Horizon pilot, which is critical as it will either validate or invalidate all of the research that we carried out in the early phases of our design.

In the next chapter, we will begin the installation of our VMware Horizon infrastructure, starting with the Horizon Connection Server.

1. Name the key functions of the Horizon Connection Server.
2. What tasks are a Horizon Composer Server responsible for?
3. What resource should you use to obtain the latest information regarding what OSes are supported for use as Horizon virtual desktops or as a Horizon Connection Server?
4. What are some reasons why you would deploy a Horizon Unified Access Gateway instead of a Horizon Security Server?
5. What versions of vSphere does the latest version of Horizon support?
6. What advantages does VMware User Environment Manager have over traditional roaming profiles?
7. What are some tools you could use to help assess your current end user computing resource requirements?
8. What is the difference between an Instant Clone and Linked Clone desktop?
9. What is the VMware recommended maximum number of desktops that you should deploy in a Horizon Pod?
10. What types of things typically impact the amount of bandwidth needed by Horizon clients?

The following resources may be used to learn more about the topics described in this chapter:

• VMware documentation:
  • VMware Horizon (https://docs.vmware.com/en/VMware-Horizon-7/index.html)
  • VMware Horizon Cloud (https://docs.vmware.com/en/VMware-Horizon-Cloud-Service/index.html)
  • VMware App Volumes (https://docs.vmware.com/en/VMware-App-Volumes/index.html)
  • VMware User Environment Manager (https://www.vmware.com/support/pubs/uem-pubs.html)
  • VMware Workspace ONE Identity Manager (https://docs.vmware.com/en/VMware-Workspace-ONE/index.html)
  • VMware vRealize Operations for Horizon (https://www.vmware.com/support/pubs/vcops-view-pubs.html)
  • • VMware Fusion (https://www.vmware.com/support/pubs/fusion_pubs.html)
  • VMware ThinApp (https://www.vmware.com/support/pubs/thinapp_pubs.html)
  • VMware vSphere (https://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html)