High-level architectural overview
In this section, we will cover the core Horizon View features and functionality for brokering virtual desktop machines that are hosted on the VMware vSphere platform.
The Horizon View architecture is pretty straightforward to understand, as its foundations lie in the standard VMware vSphere products (ESXi and vCenter). So, if you have the necessary skills and experience of working with this platform, then you are already nearly halfway there.
Horizon View builds on the vSphere infrastructure, taking advantage of some of the features of the ESXi hypervisor and vCenter Server. Horizon View requires adding a number of virtual machines to perform the various View roles and functions.
An overview of the View architecture for delivering virtual desktops is shown in the following diagram:
View components run as applications that are installed on the Microsoft Windows Server operating system, with the exception of the Access Point, which is a hardened Linux appliance, so it could actually run on physical hardware as well. However, there are a great number of benefits available when you run them as virtual machines, such as delivering HA and DR, as well as the typical cost savings that can be achieved through virtualization.
The following sections will cover each of these roles/components of the View architecture in greater detail, starting with the Horizon View Connection Server.
Horizon View Connection Server
The Horizon View Connection Server, sometimes referred to as Connection Broker or View Manager, is the central component of the View infrastructure. Its primary role is to connect a user to their virtual desktop by means of performing user authentication, and then delivering the appropriate desktop resources based on the user's profile and user entitlement. When logging on to your virtual desktop, it is the connection server that you are communicating with.
How does the Connection Server work?
A user will typically connect to their virtual desktop machine from their end-point device by launching the View client, but equally, they could use browser-based access. We will cover the View client and other access methods in Chapter 8, Horizon View Client Options .
So how does the login process work? Once the View client has launched (shown as 1 in the next diagram), the user enters the address details of the View Connection Server, which in turn responds (2) by asking them to provide their network login details (their Active Directory (AD) domain username and password).
Note
It's worth noting that Horizon View now supports the following different AD Domain functional levels:
- Windows Server 2003
- Windows Server 2008 and 2008 R2
- Windows Server 2012 and 2012 R2
Based on the user's entitlements, these credentials are authenticated with AD (3) and, if successful, the user is able to continue the logon process. Depending on what they are entitled to, the user could see a launch screen that displays a number of different virtual desktop machine icons that are available for them to log in to. These desktop icons represent the desktop pools that the user has been entitled to use.
A pool is basically a collection of similar virtual desktop machines; for example, it could be a pool for the marketing department where the virtual desktop machines contain specific applications/software for that department. We will discuss desktop pools in greater detail in Chapter 7, Managing and Configuring Desktop Pools.
Once authenticated, the View Manager or Connection Server makes a call to the vCenter Server (4) to create a virtual desktop machine, and then vCenter makes a call (5) to either View Composer (if you are using Linked Clones) or will create an Instant Clone using the VM Fork feature of vSphere to start the build process of the virtual desktop if there is not one already available for the user to log in to.
When the build process has completed and the virtual desktop machine is available to the end user, it is displayed/delivered within the View Client window (6) using the chosen display protocol (PCoIP, Blast, or RDP).
This process is described pictorially in the following diagram:
There are other ways to deploy VDI solutions that do not require a connection broker, although you could argue that strictly speaking, this is not a true VDI solution. This is actually what the first VDI solutions looked like, and just allowed a user to connect directly to their own virtual desktop via RDP. If you think about it, there are actually some specific use cases for doing just this.
For example, if you have a large number of remote branches or offices, you could deploy local infrastructure allowing users to continue working in the event of a WAN outage or poor network communication between the branch and head office. The infrastructure required would be a subset of what you deploy centrally in order to keep costs minimal.
It just so happens that VMware have also thought of this use case and have a solution that's referred to as a Brokerless View, which uses the VMware Horizon View Agent Direct-Connection plugin to connect directly to a virtual desktop machine without needing the Connection Server. However, don't forget that in a Horizon View environment, the View Connection Server provides greater functionality and does much more than just connecting users to desktops, as we will see later in this chapter.
As we previously touched on, the Horizon View Connection Server runs as an application on a Windows server, which could be either a physical or a virtual machine. Running as a virtual machine has many advantages; for example, it means that you can easily add high-availability features, which are critical in this environment, as you could potentially have hundreds or maybe even thousands of virtual desktop machines running on a single host server.
Along with brokering the connections between the users and virtual desktop machines, the Connection Server also works with vCenter Server to manage the virtual desktop machines. For example, when using Linked Clones or Instant Clones and powering on virtual desktops, these tasks are initiated by the Connection Server, but they are executed at the vCenter Server level.
Now that we have covered what the Connection Server is and how it works, in the next section, we are going to look at the requirements you need for it to run.
Minimum requirements for the Connection Server
To install the View Connection Server, you need to meet the following minimum requirements to run on physical or virtual machines:
- Hardware requirements: The following table shows the hardware required:
- Supported operating systems: The View Connection Server must be installed on one of the operating systems listed in the following table:
In the next section, we are going to look at the Horizon View Security Server.
The Horizon View Security Server
The Horizon View Security Server is another component in the architecture and is essentially another version of the View Connection Server, but this time, it sits within your DMZ so that you can allow end users to securely connect to their virtual desktop machine from an external network or the Internet. As you will see in Chapter 4, Installing and Configuring Horizon View, the installation process is pretty much the same as installing the View Connection Server, but instead, you select the Security Server role from the drop-down menu at the start of the installation.
Note
You cannot install the View Security Server on the same machine that is already running as a Connection Server or any of the other Horizon View components.
How does the Security Server work?
To start with, the user login process at the beginning is the same as when connecting to a View Connection Server, essentially because the Security Server is just another version of the Connection Server running a subset of the features, with the exclusion of the ADAM database. The difference is that you connect to the address of the Security Server. The Security Server sits inside your DMZ and communicates with a Connection Server sitting on the internal network that it is paired with. So, now we have added an extra security layer as the internal Connection Server is not exposed externally, with the idea being that users can now access their virtual desktop machines externally without needing to first connect to a VPN on the network first.
Note
The Security Server should not be joined to the Domain.
This process is described pictorially in the following diagram:
We mentioned previously that the Security Server is paired with a Connection Server. The pairing is configured by the use of a one-time password during installation. It's a bit like pairing your smartphone with the hands-free kit in your car using Bluetooth.
We will cover this in the Installing of the Security Server section in Chapter 4, Installing and Configuring Horizon View.
When the user logs in from the View Client, they now use the external URL of the Security Server to access the Connection Server, which in turn authenticates the user against AD. If the Connection Server is configured as a PCoIP gateway, then it will pass the connection and addressing information to the View Client. This connection information will allow the View Client to connect to the Security Server using PCoIP. This is shown in the diagram by the green arrow (1). The Security Server will then forward the PCoIP connection to the virtual desktop machine (2), creating the connection for the user. The virtual desktop machine is displayed/delivered within the View Client window (3) using the chosen display protocol (PCoIP, Blast, or RDP).
The Horizon View Replica Server
The Horizon View Replica Server, as the name suggests, is a replica or copy of a View Connection Server and serves two key purposes.
The first is that it is used to enable high availability to your Horizon View environment. Having a replica of your View Connection Server means that, if the Connection Server fails, users are still able to connect to their virtual desktop machines.
Secondly, adding Replica Servers allows you to scale up the number of users and virtual desktop connections. An individual instance of a Connection Server can support 2000 connections, so adding additional Connection Servers allows you to add another 2000 users at a time, up to the maximum of five connection servers and 10,000 users per Horizon View Pod. We will discuss the Pod and Block architecture in Chapter 3, Design and Deployment Considerations.
When deploying a Replica Server, you will need to change the IP address or update the DNS record to match this server if you are not using a load balancer.
As with the Security Server, you will see, in Chapter 4, Installing and Configuring Horizon View, that the installation process is again almost the same as the Connection Server, but this time, you select the Replica Server role from the drop-down menu with the different role options.
How does the Replica Server work?
So, the first question is, what actually gets replicated? The Connection Broker stores all its information relating to the end users, desktop pools, virtual desktop machines, and other View-related objects, in an Active Directory Application Mode (ADAM) database. Then, using the Lightweight Directory Access Protocol (LDAP) (it uses a method similar to the one AD uses for replication), this View information gets copied from the original Connection Server to the Replica Server.
As both the Connection Server and the Replica Server are now identical to each other, if your Connection Server fails, then you essentially have a backup that steps in and takes over, so that end users can continue to connect to their virtual desktop machines.
Just like with the other components, you cannot install the Replica Server role on the same machine that is running as a Connection Server or any of the other Horizon View components.
The Horizon View Enrollment Server and True SSO
The Horizon View Enrollment Server is the final component that is part of the Horizon View Connection Server installation options, and is selected from the drop-down menu from the installation options screen. So, what does the Enrollment Server do?
Horizon 7 sees the introduction of a new feature, called True SSO. True SSO is a solution that allows a user to authenticate to a Microsoft Windows environment without them having to enter their AD credentials. It integrates into another VMware product, VMware Identity Manager, which forms part of both Horizon 7 Advanced and Enterprise editions.
Its job is to sit between the Connection Server and the Microsoft Certificate Authority and to request temporary certificates from the certificate store.
This process is described pictorially in the following diagram:
A user first logs in to VMware Identity Manager, either using their credentials or other authentication methods such as the following:
- RSA SecurID
- Kerberos
- RADIUS authentication
- RSA Adaptive Authentication
- Standards-based third-party identity providers
Once successfully authenticated, the user will be presented with the virtual desktop machines or hosted applications that they are entitled to use. They can launch any of these by simply double-clicking, which will launch the Horizon View Client, as shown by the red arrow (1) in the previous diagram. The user's credentials will then be passed to the Connection Server (2), which in turn will verify them by sending a Security Assertion Markup Language (SAML) assertion back to the Identity Manager (3).
If the user's credentials are verified, then the Connection Server passes them on to the Enrollment Server (4). The Enrollment Server then makes a request to the Microsoft Certificate Authority (CA) to generate a short-lived, temporary certificate for that user to use (5).
With the certificate now generated, the Connection Server presents it to the operating system of the virtual desktop machine (6), which in turn validates with Active Directory as to whether or not the certificate is authentic (7).
When the certificate has been authenticated, then the user is logged on to their virtual desktop machine, which will be displayed/delivered to the View Client using the chosen display protocol (8).
Note
True SSO is supported with all Horizon 7 supported desktop operating systems for desktops, as well as Windows Server 2008 R2 and Windows Server 2012 R2. It also supports PCoIP, HTML, and Blast Extreme delivery protocols.
VMware Access Point
VMware Access Point performs exactly the same functionality as the View Security Server, as shown in the following diagram, with one key difference. Instead of being a Windows application and another role of the Connection Server, the Access Point is a separate virtual appliance that runs a hardened, locked-down Linux operating system:
Although the Access Point Appliances deliver pretty much the same functionality as the Security Server, it does not yet completely replace it, especially if you already have a production deployment that uses the Security Server for external access. You can continue to use this architecture.
Note
If you are using the secure tunnel function, PCoIP Secure Gateway, or the Blast Secure Gateway features of the Connection Server, then these features will need to be disabled on the Connection Server if you are using the Access Point. They are all enabled by default on the Access Point Appliances.
A key difference between the Access Point Appliances and the Security Server is in the way it scales. Before, you had to pair a Security Server with a Connection Server, which was a limitation, but this is no longer the case. As such, you can now scale to as many Access Point appliances as you need for your environment, with the maximum limit being around 2000 sessions for a single appliance. Adding additional appliances is simply a case of deploying the appliance, as appliances don't depend on other appliances and do not communicate with them. They communicate directly with the Connection Servers.