上QQ阅读APP看书，第一时间看更新

How does the connection server work?

A user will connect to their VDI desktop using their endpoint device by first launching the Horizon Client, but, equally, they could use browser-based access. We will cover the Horizon clients and other access methods in Chapter 12, Horizon Client Options.

So, what happens next, and how does the login process work? Once the Horizon client has launched, the end user enters the address details of the View Connection server they want to connect to (1), which in turn responds (2) by asking them to provide their network login details, their Active Directory domain username, and their password.

It's worth noting that Horizon View now supports the following different AD Domain functional levels:

Windows Server 2003
Windows Server 2008 and Windows Server 2008 R2
Windows Server 2012 and Windows Server 2012 R2
Windows Server 2016

The end users' credentials are authenticated with Active Directory (3) and, if successful, the user can continue the login process. Depending on what resources they are entitled to, the end user will see a launch screen that displays a few 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. They may well also see application icons representing published applications.

A desktop 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 and software for that department. We will discuss desktop pools in more detail in Chapter 8, Configuring and Managing Desktop Pools – Part 1.

Once authenticated, the view manager or the 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 it 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.

As part of the overall build process, at this point, if configured, VMware UEM will load the end user's profile, personalizing and customizing the virtual desktop to that individual user. The same applies to VMware app volumes, which, if configured, will now deliver any layered applications at the same time.

When the build process has completed, and the virtual desktop machine is available to the end user, complete with their profile and applications, it is displayed or delivered within the Horizon Client window (6) or browser, using the chosen display protocol PCoIP, Blast Extreme, 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. As we discussed in the introduction and history, this is what the first VDI solutions looked like, allowing an end user to connect directly to their own virtual desktop via the RDP protocol. If you think about it, though, there are still some specific use cases for doing it this way.

For example, if you have a large number of remote branches or offices, you could deploy a subset of the infrastructure, hosting it on the local site, allowing users to continue working in the event of a WAN outage or poor network communication between the branch and head office.

It just so happens that VMware also thought of this as a use case and has a solution that's referred to as a Brokerless View, which uses the VMware Horizon view agent DirectConnection plugin to connect directly to a virtual desktop machine without needing the connection server. This was originally part of the Desktone Desktop as a Service (DaaS) solution that VMware acquired in October 2013. However, don't forget that in a Horizon View environment, the view connection server provides greater functionality and does much more than just connect users to desktops, as we will see later in this chapter.

Along with brokering the connections between the end users and the virtual desktop machines, the view connection server also works with the 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 by the vCenter server.

Now that we have covered what the connection server is and given you an overview of how it works, in the next section, we are going to look at the requirements you need in order for it to run.