Whether it is Horizon, XenDesktop, or a cloud-based Desktop-as-a-Service provider, the implementation of a virtual desktop and/or published applications environment requires a significant time investment during the design phase.  If care isn’t taken, the wrong design could be put into production, and the costs of fixing it could easily outweigh the benefits of implementing the solution.

So before we move into installing the actual components for a Horizon environment, we’ll spend the next two posts on design considerations.  This post, Part 3, will discuss design considerations for the Horizon virtual desktops, and Part 4 will discuss design considerations for Active Directory.

Before I begin, designing an infrastructure to support a virtual desktop environment is a complex process. I couldn’t do it justice in one blog post. This post will provide an overview of the topic and help you understand all of the considerations that go into designing an environment. If you want to learn more about the art and science of designing VDI environments, I highly recommend The VDI Design Guide by Johan van Amersfoort.

Virtual Desktop Design

Virtual desktop environments are all about the end user and what they need.  So before you go shopping for storage arrays and servers, you need to start looking at your desktops.

Typically, when people think about desktop design, the first thing they think about is what provisioning engine they want to use. This is not the place to start. However, since this is one of the things that people want to know more about, I’ll start by discussing the provisioning methods in Horizon.

There are four methods for provisioning desktops in Horizon 2006:

• Full Clone Desktops – Each desktop is a full virtual machine deployed from a template and managed as an independent virtual machine.
• Instant Clone Desktops – Instant Clone desktops are new to Horizon 7, and they are built off of the VMfork technology introduced with vSphere 6.0.  Instant Clones are essentially a rapid clone of a running virtual machine with extremely fast customization.
• Remote Desktop Session Host Pools – Horizon 6 expanded RDSH support to include PCoIP support and application remoting.  When RDSH desktops and/or application remoting are used, multiple users are logged into servers that host user sessions.  This feature requires Server 2012 R2 or newer with the RDSH features enabled.
• Manually Provisioned Desktops – Manually provisioned desktops are desktop or published app resources that are provisioned outside of Horizon. These can be virtual machines that are managed by vCenter, or unmanaged physical or virtual machines.

I didn’t mention Linked Clones here. While Linked Clones are still available in Horizon 8, they have been officially deprecated, and Composer is slated to be removed in a future release. Instant Clones are the replacement for Linked Clones, and they are available in all Horizon 8 SKUs. If you currently use Linked Clones, you will want to transition to Instant Clones, and if you are starting a new project, you should not consider Linked Clones if you are using Horizon 8.

Desktops are more than just how they are provisioned. There are also options for how the desktops get assigned to users.

There are two desktop assignment types for desktop pools:

• Dedicated Assignment – users are assigned to a particular desktop during their first login, and they will be logged into this desktop on all subsequent logins.
• Floating Assignment – users are temporarily assigned to a desktop on each login.  On logout, the desktop will be available for other users to log into.  A user may not get the same desktop on each login.

As I mentioned above, there is a lot more to desktop design than the provisioning and assignment method. It also involves the VM specifications, applications, peripherals, and other attributes of the desktop environment. In fact, these attributes may determine what provisioning methods are available to you.

Understanding Use Cases

When you design a virtual desktop environment, you have to design around the use cases.  Use cases are the users, applications, peripherals, and how they are used to complete a task, and they are used to define many of the requirements in the environment.  The requirements of the applications in the type of desktops that are used and how they are assigned to users.

Unless you have some overriding constraints or requirements imposed upon your virtual desktop project, the desktop design choices that you make will influence and/or drive your subsequent purchases.   For instance, if you’re building virtual desktops to support CAD users, blade servers aren’t an option because high-end graphics cards will be needed, and if you want/need full clone desktops, you won’t invest in a storage array that doesn’t offer deduplication.

Other factors that may impact the use cases or the desktop design decisions include existing management tools, security policies, and other policies.

The Importance of Desktop Assessments

So how do you define your use cases? What information do you need, and how do you collect it?

The knowledge of who the users are collectively, the applications and peripherals they use, and how often they use them may exist in the organization, but there is a good chance that this information is tribal knowledge, outdated, and may be missing key details.

This is where desktop assessments come in. A desktop assessment is a process that gathers information about the environment to assist in defining use cases and sizing requirements for an environment.

The assessment starts by deploying an application in the environment. This typically consists of a server or virtual appliance that processes data and an agent that is deployed on endpoints. The tool runs for at least 30 days to gather information from a full business cycle.

When the assessment is complete, you will have detailed information about the application and resource usage, which will help determine the virtual desktop sizing and, later in the project, the physical infrastructure requirements.

Putting Together a High Level Design

Once you have determined your use cases, completed a desktop assessment and understand the impacts that these have on the desktop design, you’ll be able to put together a design document with the following items:

• Use Case definition, which includes the applications, peripherals, and other aspects of the user environment.

The use case definitions will then determine other aspects of the environment, including:

• Desktop definition based on the assessment data
• Number of parent images that need to be managed
• Number and type of desktop pools
• Number of desktops per pool
• Number of Connection Servers and Unified Access Gateways that are required

If you’re following the methodology that VMware uses in their design exams, your desktop design document should provide you with your conceptual and logical designs.

The conceptual and logical designs, built on details from the use cases, will influence the infrastructure design.  This phase would cover the physical hardware to run the virtual desktop environment, the network layer, storage fabric, and other infrastructure services such as antivirus.

The desktop design document will have a heavy influence on the decisions that are made when selecting components to implement Horizon 7.  The components that are selected need to support and enable the type of desktop environment that you want to run.

Before moving onto the next section, I want to reiterate the importance of doing a desktop assessment. The assessment will provide you with the information you need to properly design the environment, and it will avoid costly mistakes.

In part four, we will cover Active Directory design for Horizon environments.

In order to deliver virtual desktops to end users, a Horizon environment requires multiple components working together in concert.  Most of the components that Horizon relies upon are VMware products, but some of the components, such as the database and Active Directory, are 3rd-party products.

The Basics

The smallest Horizon environment only requires three components to deliver a remote desktop session to end users: a desktop, a View Connection Server, and Active Directory.  Technically speaking, you do not need vCenter or ESXi as the Horizon agent can be installed on physical desktops.

Many environments, though, are built on vSphere, and the virtual infrastructure for this type of environment doesn’t need to be anything special.  For small proof of concepts or upgrade testing, one server with direct attached storage and enough RAM could support a few users.

All Horizon environments, from the simple one above to a complex multi-site Cloud Pod environment, are built on this foundation.  The core of this foundation is the View Connection Server.

Connection Servers are at the core of a Horizon environment.  They handle desktop provisioning, user authentication and broker user sessions to desktops.  They manage connections to multi-user desktops and published applications.

There are three roles that can be installed using the Connection Server installer, and all three roles have the same requirements.  These roles are:

• Standard Connection Server – The first Connection Server installed in the environment.
• Replica Connection Server – Additional Connection Servers that replicate from the standard connection server
• Enrollment Server – The Enrollment Server was introduced in Horizon 7.  role is used to facilitate the new True SSO feature in conjunction with Workspace ONE Access and a local certificate authority.

The requirements for a Connection Server are:

• 1 CPU, 4 vCPUs recommended
• Minimum 4GB RAM, 10GB recommended if 50 or more users are connecting
• Windows Server 2012 R2 or newer
• Joined to an Active Directory domain
• Static IP Address

Note: The requirements for the Enrollment Server are the same as the requirements for Connection Server.

Aside from the latest version of the Connection Server, the requirements are:

ESXi – ESXi is required for hosting the virtual machine The versions of ESXi that are supported by Horizon 2006 can be found in the VMware compatibility matrix.

vCenter Server – The versions of vCenter that are supported by Horizon 2006 can be found in the VMware compatibility matrix.

Active Directory – An Active Directory environment is required to handle user authentication to virtual desktops, and the domain must be set to at least the Server 2012 R2 functional level.  Group Policy is used for configuring parts of the environment, including desktop settings, user data redirection, UEM, and the remoting protocol.

Advanced Features

Horizon has a lot of features, and many of those features require additional components to take advantage of them.  These components add options like secure remote access, profile management, and instant clone desktops.

Secure Remote Access – The options for delivering secure remote access with Horizon have been simplified in Horizon 2006.  Traditionally, remote access had been provided by the Horizon Security Server, but this feature has been removed.  The Unified Access Gateway replaces the Security Server for all remote access functionality.

Networking Requirements – Horizon requires a number of ports to be opened to allow communication between the user’s endpoint and the remote desktop as well as communication between the management components.  The best source for showing all of the ports required by the various components is the VMware Horizon Network Ports diagram.  The Network Ports diagram can be found on TechZone.

Instant Clone Desktops – Instant Clones are a rapid desktop provisioning model.  With instant clones, desktops are created when the user signs in and are provisioned and ready to use within seconds.  When the user signs out, the desktop is destroyed.  Instant clones allow for elastic capacity and rolling image upgrades.  They support both floating and dedicated desktops.

One new feature of Horizon 2006 is a change to the Instant Clone provisioning model.  In Horizon 7, Instant Clones relied on a tree of VMs, including a powered-on parent VM on each host in the cluster that all of the desktops are forked from.  An additional deplopyment model is being added in Horizon 2006 that enables the benefits of Instant Clones without having to have that parent VM consuming resources on each host.

Other Components:  The Horizon Suite includes a number of tools to provide administrators with a full-fledged ecosystem for managing their virtual end-user computing environments.  These tools are App Volumes, Dynamic Environment Manager, and an on-premises version of Workspace ONE Access.

Horizon subscription licensing, including Horizon Universal Licensing, include the Horizon Service and it’s associated cloud features including Cloud Monitoring Service, Image Management Service, and Universal Broker, and an entitlement to ControlUp for user experience monitoring. The Horizon subscription licensing SKUs are required for running Horizon on cloud-based SDDCs like VMware Cloud on AWS, Azure VMware Service, and Google Cloud VMware Engine. These licenses also allow customers to utilize Horizon Cloud on Azure and Horizon Cloud on IBM Cloud.

The last time VMware released a new major version of Horizon was back in 2016.  In the four years since Horizon 7 was released, there have been significant additions to the core product, including HTML5-based management and support consoles, significant enhancements to the Blast protocol and the Instant Clone provisioning model, the introduction of an Extended Service Branch for long-term support, and new client redirection features to support access to local drives, Skype for Business, and multimedia redirection.

Today, VMware has released the next major release of VMware Horizon.  Horizon 8, also known as Horizon 2006, brings several changes to the platform.  Some of these changes are large changes that bring new functionality to the platform, and other changes are deprecating or removing obsolete features.

Some of the features that are being removed, and their replacements are:

*Note: Linked Clones, Composer, and Persistent Disks are deprecated.  All other features listed have been removed from Horizon 2006.

Some of these changes have been in the works for a while.  Instant Clones have been around since Horizon 7 was released in 2016, and they have seen significant improvements with every release.  As part of Horizon 2006, Instant Clones will no longer be restricted to Horizon Enterprise and Horizon Apps Advanced.  Unified Access Gateway has been the designated Security Server replacement for a while now.

One of the most visible changes that comes with Horizon 8 is a change in branding and versioning.  Horizon is now moving to a naming scheme that involves the month and the year in the version that is in line with how many other brand their products.  This will make it easier to keep track of when a version is released. The first release of Horizon 8 will be 2006.

Some of the other changes that are included with Horizon 2006 are:

• Expanded REST API that includes new primitives for managing entitlements and inventory items such as desktop pools and RDSH farms.
• A new Instant Clone provisioning model that frees up resources on hosts by removing the instant clone parent VM that is deployed on each host.
• Built-in digital watermarking tool to help protect intellectual property in virtual desktops

This is not an inclusive list, so please be sure to check out the release blog.  There will be more content explaining these features on Techzone in the coming days.

Series Overview

If you noticed the title, this is part 1 of a new series on Horizon.  The first part of this series will focus doing a basic Horizon architecture and setup.  After that, I hope to move into more advanced topics as time allows.  These include those that were not covered in my last series (or were left unfinished), including App Volumes, DEM, and RDSH.

One of the common questions I see is around integrating VMware Horizon with Microsoft Azure MFA. Natively, Horizon only supports RSA and RADIUS-based multifactor authentication solutions. While it is possible to configure Azure MFA to utilize RADIUS, it requires Network Policy Server and a special plugin for the integration (Another option existed – Azure MFA Server, but that is no longer available for new implementations as of July 2019).

Earlier this week, VMware released Horizon 7.11 with Unified Access Gateway 3.8. The new UAG contains a pretty cool new feature – the abilility to utilize SAML-based multifactor authentication solutions.  SAML-based multifactor identifaction allows Horizon to consume a number of modern cloud-based solutions.  This includes Microsoft’s Azure MFA solution.

And…you don’t have to use TrueSSO in order to implement this.

If you’re interested in learning about how to configure Unified Access Gateways to utilize Okta for MFA, as well as tips around creating web links for Horizon applications that can be launched from an MFA portal, you can read the operational tutorial that Andreano Lanusso wrote.  It is currently available on the VMware Techzone site.

Prerequisites

Before you can configure Horizon to utilize Azure MFA, there are a few prerequisites that will need to be in place.

First, you need to have licensing that allows your users to utilize the Azure MFA feature.  Microsoft bundles this into their Office 365 and Microsoft 365 licensing skus as well as their free version of Azure Active Directory.

Note: Not all versions of Azure MFA have the same features and capabilities. I have only tested with the full version of Azure MFA that comes with the Azure AD Premium P1 license.  I have not tested with the free tier or MFA for Office 365 feature-level options.

Second, you will need to make sure that you have Azure AD Connect installed and configured so that users are syncing from the on-premises Active Directory into Azure Active Directory.  You will also need to enable Azure MFA for users or groups of users and configure any MFA policies for your environment.

If you want to learn more about configuring the cloud-based version of Azure MFA, you can view the Microsoft documentation here.

There are a few URLs that we will need when configuring single sign-on in Azure AD.  These URLs are:

• Portal URL: https://horizon.uag.url/portal
• SAML URL: https://horizon.uag.url/portal/samlsso

Case sensitivity matters here.  If you put caps in the SAML URL, you may receive errors when uploading your metadata file.

Configuring Horizon UAGs as a SAML Application in Azure AD

The first thing we need to do is create an application in Azure Active Directory.  This will allow the service to act as a SAML identity provider for Horizon.  The steps for doing this are:

1. Sign into your Azure Portal.  If you just have Office 365, you do have Azure Active Directory, and you can reach it from the Office 365 Portal Administrator console.
2. Go into the Azure Active Directory blade.
3. Click on Enterprise Applications.
   
4. Click New Application.
   
5. Select Non-Gallery Application.
   
6. Give the new application a name.
   
7. Click Add.
8. Before we can configure our URLs and download metadata, we need to assign users to the app.  Click 1. Assign Users and Groups
   
9. Click Add User
   
10. Click where it says Users and Groups – None Selected.
    
11. Select the Users or Groups that will have access to Horizon. There is a search box at the top of the list to make finding groups easier in large environments.
    Note: I recommend creating a large group to nest your Horizon user groups in to simplify setup.
12. Click Add.
13. Click Overview.
    
14. Click 2. Set up single sign on.
    
15. In the section labeled Basic SAML Configuration, click the pencil in the upper right corner of the box. This will allow us to enter the URLs we use for our SAML configuration.
    
16. Enter the following items.  Please note that the URL paths are case sensitive, and putting in PORTAL, Portal, or SAMLSSO will prevent this from being set up successfully:
    1. In the Identifier (Entity ID) field, enter your portal URL.  It should look like this:
       https://horizon.uag.url/portal
    2. In the Reply URL (Assertion Consumer Service URL) field, enter your uag SAML SSO URL.  It should look like this:
       https://horizon.uag.url/portal/samlsso
    3. In the Sign on URL, enter your uag SAML SSO URL.  It should look like this:
       https://horizon.uag.url/portal/samlsso
       
17. Click Save.
18. Review your user attributes and claims, and adjust as necessary for your environment. Horizon 7 supports logging in with a user principal name, so you may not need to change anything.
19. Click the download link for the Federation XML Metadata file.
    

We will use our metadata file in the next step to configure our identity provider on the UAG.

Once the file is downloaded, the Azure AD side is configured.

Configuring the UAG

Once we have completed the Azure AD configuration, we need to configure our UAGs to utilize SAML for multifactor authentication.

In order to do these steps, you will need to have an admin password set on the UAG appliance in order to access the Admin interface.  I recommend doing the initial configuration and testing on a non-production appliance.  Once testing is complete, you can either manually apply the settings to the production UAGs or download the configuration INI file and copy the SAML configuration into the production configuration files for deployment.

Note: You can configure SAML on the UAGs even if you aren’t using TrueSSO.  If you are using this feature, you may need to make some configuration changes on your connection servers.  I do not use TrueSSO in my lab, so I have not tested Azure MFA on the UAGs with TrueSSO.

The steps for configuring the UAG are:

1. Log into the UAG administrative interface.
2. Click Configure Manually.
3. Go to the Identity Bridging Settings section.
4. Click the gear next to Upload Identity Provider Metadata.
   
5. Leave the Entity ID field blank.  This will be generated from the metadata file you upload.
6. Click Select.
   
7. Browse to the path where the Azure metadata file you downloaded in the last section is stored.  Select it and click Open.
   
8. If desired, enable the Always Force SAML Auth option.
   Note: SAML-based MFA acts differently than RADIUS and RSA authentication. The default behavior has you authenticate with the provider, and the provider places an authentication cookie on the machine. Subsequently logins may redirect users from Horizon to the cloud MFA site, but they may not be force to reauthenticate. Enabling the Always Force SAML Auth option makes SAML-based Cloud MFA providers behave similiarly to the existing RADIUS and RSA-based multifactor solutions by requiring reauthentication on every login. Please also be aware that things like Conditional Access Policies in Azure AD and Azure AD-joined Windows 10 devices may impact the behavior of this solution.
9. Click Save.
   
10. Go up to Edge Services Settings and expand that section.
11. Click the gear icon next to Horizon Edge Settings.
12. Click the More button to show all of the Horizon Edge configuration options.
13. In the Auth Methods field, select one of the two options to enable SAML:
    1. If you are using TrueSSO, select SAML
    2. If you are not using TrueSSO, select SAML and Passthrough
       
14. Select the identity provider that will be used.  For Azure MFA, this will be the one labeled https://sts.windows.net
    
15. Click Save.

SAML authentication with Azure MFA is now configured on the UAG, and you can start testing.

User Authentication Flows when using SAML

Compared to RADIUS and RSA, user authentication behaves a little differently when using SAML-based MFA.  When a user connects to a SAML-integrated environment, they are not prompted for their RADIUS or RSA credentials right away.

After connecting to the Horizon environment, the user is redirected to the website for their authentication solution.  They will be prompted to authenticate with this solution with their primary and secondary authentication options.  Once this completes, the Horizon client will reopen, and the user will be prompted for their Active Directory credentials.

You can configure the UAG to use the same username for Horizon as the one that is used with Azure AD, but the user will still be prompted for a password unless TrueSSO is configured.

Over the last couple of releases, VMware has included an HTML5-based Horizon Console for managing Horizon 7.  Each release has brought this console closer to feature parity with the Flash-based Horizon Administrator console that is currently used by most administrators.

With the end-of-life date rapidly approaching for Adobe Flash, and some major browsers already making Flash more difficult to enable and use, there will be some changes coming to Horizon Administration.

• The HTML5 console will reach feature parity with the Flash-based Horizon Administrator in the next release.  This includes a dashboard, which is one of the major features missing from the HTML5 console.  Users will be able to access the HTML5 console using the same methods that are used with the current versions of Horizon 7.
• In the releases that follow the next Horizon release, users connecting to the current Flash-based console will get a page that provides them a choice to either go to the HTML5 console or continue to the Flash-based console.  This is similar to the landing page for vCenter where users can choose which console they want to use.

More information on the changes will be coming as the next version of Horizon is released.