Horizon REST API Library for .Net

So…there is a surprise second post for today. This one is a short one, and if you’ve been interested in automating your Horizon deployment, you will like this.

Previous versions of Horizon had APIs – most famously the SOAP API that was exposed through PowerShell. Horizon 7 first introduced a REST API last year, but that API was limited to mostly read-only operations.

One of the new features of Horizon 2006 is an expand REST API. The expanded REST API provides administrators with the ability to easily automate pool management and entitlement tasks. You can learn more about the REST API by reviewing the Getting Started guide on Techzone, and you can browse the entire API on VMware Code.

Adopting this API to develop applications for Horizon has gotten easier. Andrew Morgan from the VMware End User Computing business unit has developed a .Net library around the Horizon Server REST API and released it on Github. This library supports both .Net 4.7 and .Net Core. The Github repo includes code samples for using the library with C# and Visual Basic.

I’m excited to see investment in this REST API as it will help customers, partners, and the community build applications to enhance and extend their Horizon deployments.

Determining Features Installed in the Horizon Agent or Windows Client

Let’s say you have a desktop pool or RDSH Farm.  You want to try out something in Horizon that requires a change to the Agent or Client, but you can’t remember if it’s been installed.  You could reinstall the agent or client to make sure the component you need is there.  But that’s a lot of manual work.

Thanks to a tip from a couple of my colleagues, including William Uhlig and Dan Berkowitz, there is an easier way to see what was installed with the Horizon Agent.  You can just check a registry key.

Inside your virtual desktops and RDSH servers, there is a registry key that shows all of the features available in the Horizon agent and whether they are available locally.  This registry key is located at HKEY_LOCAL_MACHINE\Software\VMware, Inc.\Installer\Features_HorizonAgent

Reg1

As you can see in the attached screenshot, features that are available have a value of “Local.”  Features that aren’t available, ie those that were not installed, as listed as being “Absent.”

There is also a registry key that shows installed features for the Horizon Client on Windows.  Horizon has a single installer that is used for both 32-bit and 64-bit Windows, so the location of this key will depend on what version of Windows you have installed. The path for this registry key on a 64-bit machine is HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMware VDM\Client\Installer\.

Inside this registry key, there will be a key named with a GUID. The contents of this field contain the list of features that are installed in the Windows Horizon Client. Unlike the Agent install key, it uses a binary value to denote if a feature is installed instead of “local” or “absent.” The Horizon Client has fewer installable options compared to the agent, and the only optional item that does not appear in this key, at least in a default installation, is URL Content Redirection. This feature require a command-line switch to enable in the Horizon Client installer.

Horizon 8.0 Part 6: Service Accounts and Databases

Back in Part 4, I mentioned that Horizon required up to a few service accounts to function properly.  One of these accounts is for accessing vCenter to provision and manage the virtual machines that users will connect to.  The other service account will manage computer accounts within Active Directory, and this account is only required if you are using Instant Clones.

Horizon 8 utilizes a single database for storing event and auditing data generated by the platform. This database is optional, but it is highly recommended. Horizon supports running the event database on Microsoft SQL Server and Oracle, and you can find the specific supported versions in the VMware Product Interoperability Matrix. This post will cover setting up the event database on Microsoft SQL Server.

It’s important to build the Active Directory service accounts and database access accounts with the principle of least privileged access in mind.  These accounts should not have more rights than they would need.  So while the easy way out would be to give these accounts vCenter Administrator, Domain Administrator, and SQL Server or Oracle SysAdmin rights, it would not be a good idea as these accounts could potentially be compromised.

vCenter Service Account

The first account that needs to be created is a service account that Horizon will use for accessing vCenter.  Horizon uses this account for virtual machine management tasks, including provisioning new virtual desktops and RDSH servers and performing power operations.  The service account can either be an Active Directory user or a local vCenter user. When installing Horizon in an on-premises environment, I prefer to use a standard Active Directory domain user account without any additional administrator-level rights on the domain or on the vCenter server.

There are a couple of different ways to configure your Horizon environment, so the actual rights required in vCenter will vary.  The specific permissions that are required can be found in the Configuring User Accounts for vCenter Access section of the Horizon documentation..

A new role will need to be created within vCenter in order to assign the appropriate permissions.  To create a new role in the vCenter Web Client, you need to go to Administration –> Roles from the main page.  This will bring up the roles page, and we can create a new role from here by clicking on the green plus sign.

2013-12-29_19-14-37

For the purposes of this walkthrough, I’ll be setting up my service account with permissions to deploy Instant Clone desktops.  These permissions will also support deploying Full Clone desktops.  The permissions that need to be assigned to our new role are:

Privilege Group Privilege
Cryptographic Operations Cryptographic Operations permissions are required if you use Instant Clones with virtual Trusted Platform Module Devices

Clone

Decrypt

Direct Access

Encrypt

Manage KMS

Migrate

Register Host

Datastore Allocate Space

Browse Datastore

Low Level File Operations

Folder Create Folder

Delete Folder

Global Act as vCenter Server*

Enable Methods

Disable Methods

Manage Custom Attributes

Set Custom Attribute

System Tag

*Required for View Storage Accelerator

Host Inventory

·         Modify Cluster

Network All Permissions
Profile Driven Storage All Permissions Required if using VSAN or Virtual Volumes
Resource Assign virtual machine to resource pool
Storage Views View
Virtual Machine Configuration

·         All Permissions

Interaction

·         Device Connection

·         Perform Wipe or Shrink Operations

·         Power Off

·         Power On

·         Reset

·         Suspend

Inventory

·         All Permissions

Provisioning

·         Allow Disk Access

·         Clone Template

·         Clone Virtual Machine

·         Customize

·         Deploy Template

·         Read Customization Specification

Snapshot Management

·         All Permissions

After the role has been created, we will need to assign permissions for our vCenter Server service account to the root object in vCenter.  This is the vCenter Server object at the top of the tree.  To do this from the roles screen, you will need to go back to the vCenter Web Client Home screen and take the following steps:

  1. Select vCenter
  2. Select vCenter Servers under Inventory Lists
  3. Select the vCenter that you wish to grant permissions on
  4. Click on the Manage Tab
  5. Click Permissions
  6. Click the Green Plus Sign to add a new permission
  7. Select the role for Horizon Composer
  8. Add the Active Directory Domain User or local vCenter user who should be assigned the role
  9. Click OK.

2013-12-29_20-33-59

Horizon Events Database Account

The Events Database is a repository for all events that happen within the Horizon environment.  Some examples of events that are recorded in the database include logon and logoff activity, an audit trail of administrator activities, and desktop provisioning errors.

The Events Database requires a Microsoft SQL Server or Oracle database server, and it should be installed on an existing production database server.  There are two parts to configuring the events database.  The first part, creating the database and the database user, needs to be done in SQL Server Management Studio before the event database can be configured in Horizon Administrator.  The steps for configuring Horizon to use the Events database will happen in another post.

Note: Horizon also supports sending event data off to a syslog server.  This can be used in place of an events database.  Configuring a syslog server is beyond the scope of this article.

When setting up a Horizon Event Database on Microsoft SQL Server, SQL Server Authentication needs to be enabled.  Horizon uses JDBC, and Windows Authentication cannot be used with the event database.

To set up the database, follow these steps:

1. Open SQL Server Management Studio and log in with an account that has permissions to create users and databases.

2. Expand Security –> Logins.

3. Right-click on Logins and Select New Login…

1. Create New User 1

4. Enter the SQL Login Name and Password and then click OK.

2. Create New User 2

5. Expand Databases.

6. Right-click on Databases and select New Database.

7. Enter the database name.  Select the database user that you created above as the database owner.  Click OK to create the database.

3. Create View Events Database

Note: SQL Server named instances are configured to use dynamic ports.  This means that SQL Server will use a new port every time the server is restarted.  The events database does not support dynamic ports, so a static port will need to be configured and the SQL instance restarted prior to configuring the events database in Horizon.  For instructions on how to configure a static ports in SQL Server, please see this article.

We have now created the shell of the database.  It is empty now, and all of the tables will be created when we configure the event database in Horizon in a future step.

Active Directory Provisioning Account

The Active Directory Provisioning Service account is used by Horizon to manage the computer accounts that are created for Instant Clone desktops.

This account can be created as a standard domain user, and it should not have domain administrator or account operator rights – it only needs a select group of permissions on the OU (or OUs) where the virtual desktop computer accounts will be placed.

After this account has been created, you need to delegate permissions to it on the OU (or OUs) where your VDI desktops will be placed.  If you use the structure like the one I outlined in Part 4, you only need to delegate permissions on the top-level OU and permission inheritance, if turned on, will apply them to any child or grandchild objects beneath it.

Note:  If inheritance is not turned on, you will need to check the Apply to All Child Objects checkbox before applying the permissions.

The permissions that need to be delegated on the OU are:

  • List Contents
  • Read All Properties
  • Write All Properties
  • Create Computer Objects
  • Delete Computer Objects
  • Read Permissions
  • Reset Password

Note: Although granting this account Domain Administrator or Account Operator permissions may seem like an easy way to grant it the permissions it needs, it will grant a number of other permissions that are not needed and could pose a security risk if that account is compromised.  Only the required permissions should be granted in a production environment.

This wraps up all of the prerequisites for the environment.  In the next couple of sections, I will be covering the installation and configuration of VMware Horizon.

Horizon 8.0 Part 5: SSL Certificates

SSL certificates are an important part of all Horizon environments .  They’re used to secure communications from client to server as well as between the various servers in the environment.  Improperly configured or maintained certificate authorities can bring an environment to it’s knees – if a connection server cannot verify the authenticity of a certificate – such as an expired revocation list from an offline root CA, communications between servers will break down.  This also impacts client connectivity – by default, the Horizon client will not connect to Connection Servers, Security Servers, or Access Points unless users change the SSL settings.

Most of the certificates that you will need for your environment will need to be minted off of an internal certificate authority.  If you are using a security server to provide external access, you will need to acquire a certificate from a public certificate authority.  If you’re building a test lab or don’t have the budget for a commercial certificate from one of the major certificate providers, you can use a free certificate authority such as Let’s Encrypt or a low-cost certificate provider such as NameCheap.

Prerequisites

Before you can begin creating certificates for your environment, you will need to have a certificate authority infrastructure set up.  Microsoft has a great 2-Tier PKI walkthrough on TechNet.

Note: If you use the walkthrough to set up your PKI environment., you will need to alter the configuration file to remove the  AlternateSignatureAlgorithm=1 line.  This feature does not appear to be supported on vCenter  and can cause errors when importing certificates.

Once your environment is set up, you will want to create a template for all certificates used by VMware products.  Derek Seaman has an older, but good, walkthrough on creating a custom VMware certificate template.

Note: Although a custom template isn’t required, I like to create one per Derek’s instructions so all VMware products are using the same template.  If you are unable to do this, you can use the web certificate template for all Horizon certificates.

Creating The Certificate Request

Horizon 8/2006 handles certificates on the Windows Server-based components the same way as previous versions of Horizon.  Certificates are stored in the Windows certificate store, so the best way of generating certificate requests is to use the certreq.exe certificate tool.  This tool can also be used to submit the request to a local certificate authority and accept and install a certificate after it has been issued.

Certreq.exe uses a custom INF file to create the certificate request.  This INF file contains all of the parameters that the certificate request requires, including the subject, the certificate’s friendly name, if the private key can be exported, and any subject alternate names that the certificate requires.

Modern browsers now require certificates to include at least one subject alternative name or they will treat the certificate as insecure. I highly recommend reviewing this article from Microsoft.  It goes over how to create a certificate request file for SAN certificates.

Your certificate request should include subject alternative names for the DNS name, fully-qualified domain name, and any load-balanced DNS name that users might use to access the system.

A  certificate request inf file that you can use as a template is below.  To use this template, copy and save the text below into a text file, change the file to match your environment, and save it as a .inf file. If you plan to use this file in your environment, please be sure to update the subject, any subject alternative names you plan to include on the certificate, and the certificate template at the bottom of the request to match the details of your environment.

;----------------- request.inf -----------------
[Version]

Signature="$Windows NT$"

[NewRequest]

Subject = "CN=<Server Name>, OU=<Department>, O=<Company>, L=<City>, S=<State>, C=<Country>" ; replace attribues in this line using example below
KeySpec = 1
KeyLength = 2048
; Can be 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
FriendlyName = "vdm"
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

[Extensions]

2.5.29.17 = "{text}"
_continue_ = "dns=<DNS Short Name>&"
_continue_ = "dns=<Server FQDN>&"
_continue_ = "dns=<Alternate DNS Name>&"

[RequestAttributes]

CertificateTemplate = VMware-SSL

;-----------------------------------------------

Note: When creating a certificate, the state or province should not be abbreviated.  For instance, if you are in Wisconsin, the full state names should be used in place of the 2 letter state postal abbreviation.

Note:  Country names should be abbreviated using the ISO 3166 2-character country codes.

Certreq.exe is typically run from the command line, and it requires administrative permissions to perform certificate operations.

The command the generate the certificate request that you can submit to your CA using the INF file is below. This will generate a new certificate request with a private key that is stored in the Windows Certificate Store.

certreq.exe –New <request.inf> <certificaterequest.req>

Submitting the Certificate Request

Once you have a certificate request, it needs to be submitted to the certificate authority.  The process for doing this can vary greatly depending on the environment and/or the third-party certificate provider that you use.

If your environment allows it, you can use the certreq.exe tool to submit the request and retrieve the newly minted certificate.  The command for doing this is:

certreq –submit -config “<ServerName\CAName>” “<CertificateRequest.req>” “<CertificateResponse.cer>

If you use this method to submit a certificate, you will need to know the server name and the CA’s canonical name in order to submit the certificate request.

Accepting the Certificate

Once the certificate has been generated, it needs to be imported into the server.  The import command is:

certreq.exe –accept “<CertificateResponse.cer>

This will import the generated certificate into the Windows Certificate Store.

Using the Certificates

Now that we have these freshly minted certificates, we need to put them to work in the Horizon environment.  There are a couple of ways to go about doing this.

1. If you haven’t installed the Horizon Connection Server components on the server yet, you will get the option to select your certificate during the installation process.  You don’t need to do anything special to set the certificate up.

2. If you have installed the Horizon components, and you are using a self-signed certificate or a certificate signed from a different CA, you will need to change the friendly name of the old certificate and restart the Connection Server.

Horizon requires the Connection Server certificate to have a friendly name value of vdm.  The template that is posted above sets the friendly name of the new certificate to vdm automatically, but this will conflict with any existing certificates.

1
Friendly Name

The steps for changing the friendly name are:

  1. Go to Start –> Run and enter MMC.exe
  2. Go to File –> Add/Remove Snap-in
  3. Select Certificates and click Add
  4. Select Computer Account and click Finish
  5. Click OK
  6. Right click on the old certificate and select Properties
  7. On the General tab, delete the value in the Friendly Name field, or change it to vdm_old
  8. Click OK
  9. Restart the Horizon service on the server

2

At this point, all of your certificates should be installed.  If you open up the Horizon Administrator web page, the dashboard should have all green lights.  If you do not see all green lights, you may need to check the health of your certificate environment to ensure that the Horizon servers can check the validity of all certificates and that a CRL hasn’t expired.

If you are using a certificate signed on an internal CA for servers that your end users connect to, you will need to deploy your root and intermediate certificates to each computer.  This can be done through Group Policy for Windows computers, deploying through Workspace ONE or other endpoint management solution, or by publishing the certificates in the Active Directory certificate store.  If you’re using Teradici PCoIP Zero Clients, you can deploy the certificates as part of a policy with the management VM.  If you don’t deploy the root and intermediate certificates, users will not be able to connect without disabling certificate checking in the Horizon client.

Unified Access Gateway Certificates

Unlike the Connection Server, the Unified Access Gateway does not run on Windows.  It is a Linux-based virtual appliance. While you might think that this make certificate management more challenging, it has been streamlined over the last few UAG releases to make it very easy. Administrators can install separate certificates for the external interface and the internal management interface during or after deployment.

The UAG certificates can be generated using Windows or OpenSSL. Be sure to include all subject alternative names in your request. Once your certificate is generated, you will either need to create a PFX file or have a copy of the private key and the certificate chain to install on the appliance.

The UAG certificates can be installed during the appliance deployment as part of the PowerShell deployment method, or they can be installed manually through the appliance management interface after the deployment is completed.

UAG certificates will be covered in greater detail when we get to the UAG section of this series.

In the next post, we’ll talk about databases and service account.

Horizon 8.0 Part 4: Active Directory Design Considerations

Traditionally, virtual desktops run Windows, and the servers that provide the virtual desktop infrastructure services also run on Windows.  Because of the heavy reliance on Windows, Active Directory plays a huge role in Horizon environments.  Even Linux desktops can be configured for Active Directory and utilize the Horizon user’s AD credentials for Single Sign-On.

When you’re planning a new Horizon deployment, or re-architecting an existing deployment, the design of your Active Directory environment is a critical element that needs to be considered.  How you organize your virtual desktops, templates, and security groups impacts Group Policy, helpdesk delegation rights, and Horizon Instant Clones and RDSH.

Some Active Directory objects need to be configured before any Horizon components are installed.  Some of these objects require special configuration either in Active Directory or inside vCenter.  The Active Directory objects that need to be set up are:

  • An organizational unit structure for Horizon Desktops and desktop templates
  • Basic Group Policy Objects for the different organizational units
  • An organization unit for Microsoft RDS servers if published apps or RDSH-desktops are deployed
  • In large environments with multiple sites and/or trusted domains, ensure that sites and services are set up properly to enable Horizon to properly locate domain controllers

Optionally, you may want to set up an organizational unit for any security groups that might be used for entitling access to the Horizon desktop pools.  This can be useful for organizing those groups and/or delegating access to Help Desk or other staff who don’t need Account Operator or Domain Administrator rights.

Horizon and Active Directory

Before I talk about creating Organizational Unit structures and Group Policy, I want to start with Active Directory architecture and how Horizon utilizes Active Directory.  I recently wrote about that here, so I won’t go too deep into that topic.  But I will recap a few things to keep in mind.

Horizon utilizes the DCLocator function that is built into the Windows Server NetLogon process.  This process utilizes DNS to identify server locator records that correspond to the Active Directory site the server is located in.

Sites and Services need to be set up properly in multisite environments.  This means that you need to create sites in AD Sites and Services, ensure that your subnets are mapped to the proper sites, and create site links for your replication topology so that Horizon can locate the closest domain controllers.

There are additional considerations around site naming when working in a multi-forest environment where domains are connected by a trust.

To learn more about Horizon and Active Directory, please see my deep dive post on the topic here.

Creating an Organizational Unit Structure for Horizon Desktops

One of the first things that we need to plan and prepare before deploying desktops is an Active Directory organizational unit structure for Horizon desktops.  This OU structure will hold all of the desktops created and used by Horizon.

A separate OU structure within your Active Directory environment is important because you will want to apply different group policies to your Horizon desktops than you would your regular desktops.  There are also specific permissions that you will need to delegate to the Horizon Instant Clone Administrator service account.

Before I go into a method of organizing Active Directory, I want to make one thing clear.  There is no one way to organize Active Directory for Horizon.  These are guidelines that I like to follow because this organization makes sense to me.  These guidelines should be modified to fit your environment and your business and technical requirements.  There are a few things I highly recommend, though:

  • A dedicated Organizational Unit tree for Virtual Deskops
  • A dedicated Organizational Unit tree for RDSH Servers
  • Creating new Group Policy Objects for virtual desktops and RDSH Servers instead of applying your standard desktop/server GPOs to these objects

My preferred organizational method looks like this:

2013-12-28_21-55-14

View Desktops is a top-level OU (ie – one that sites in the root of the domain).  I like to set up this OU for two reasons.  One is that is completely segregates my VDI desktops from my non-VDI desktops and servers.  The other is that it gives me one place to apply group policy that should apply to all VDI desktops.

I create three child OUs under the View Desktops OU to separate persistent desktops, non-persistent desktops, and desktop templates.  This allows me to apply different group policies to the different types of desktops.  For instance, you may want to disable Windows Updates and use Dynamic Environment Manager on non-persistent desktops but allow Windows Updates on the desktop templates or Persistent Desktops.

You don’t need to create all three OUs.  If your environment consists entirely of Persistent desktops, you don’t need an OU for non-persistent desktops.  The opposite is true as well.  You may also choose to create more OUs depending on your organization.  For instance, you may create OUs based business groups, regions or geography, or other ways.

Finally, I tend to create use-case specific OUs for pools that require additional Group Policy options above and beyond the top-level. These grandchild OUs are completely optional.  If there is no need to set any custom policy for a specific use case, then they don’t need to be created.  However, if a grandchild OU is needed, then an entire pool will need to be created as desktop pools are assigned to OUs.  Adding additional pools can add management overhead to a VDI environment.

I’ve found that there is less of a need for these use-case specific OUs as I’ve learned more about modern UEM tools like Dynamic Environment Manager.  These tools can be a scalpel that allow administrators to dynamically apply context-aware policies and settings to specific users or groups without having to create additional pools or OUs for Group Policy configurations.

Creating an Organizational Unit for RDS Servers

RDSH servers need to be handled differently than virtual desktops.  They’re managed differently than your virtual desktops..

If application remoting or multi-user desktops are going to be deployed, an organizational unit for RDS servers should be created.  This can be a child OU of a server organizational unit, but it may not be the best place.

If full clone or manually provisioned RDSH servers are being used, you may want to consider creating a maintenance OU.  RDSH servers are often heavily locked down to block Windows Updates, software installers, and access to administrative tools and the command prompt through Group Policy.  A maintenance OU would be an OU where these policies are not enforced, allowing admins access to these tools after a reboot to perform maintenance tasks.

One key thing to keep in mind is that server GPOs can be restrictive in some organizations, and they may conflict with applications or process that run in the RDSH server.  If RDSH is new to your environment, it’s important that the security and server teams understand that even though these are virtual machines running a server OS, they are being used like desktops to run applications.  Less restrictive server policies may be required.

Horizon Group Policy Objects

Horizon contains a number of custom group policy objects that can be used for configuring the Horizon agent features and optimizing the PCoIP and Blast protocols. The templates are available in the Horizon Extras bundle on My VMware.

The templates are distributed in ADMX format, and they can be placed in the Group Policy Central Store.

Horizon Service Accounts

Horizon requires a service account for accessing vCenter to provision new virtual machines.  If Instant Clones are used, a second service account will be needed to create computer accounts in Active Directory for managing computer accounts for the clones.  I will cover setting up those account in a future section.

In the next section, I’ll cover SSL certificates for Horizon servers.

Horizon 8.0 Part 3: Design Considerations

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 Windows Server 2008 R2 or Server 2012 R2 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.

Horizon 8.0 Part 2: Horizon Requirements

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.

Horizon 8.0 Part 1: Introduction

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:

Deprecated/Removed Feature Replacement
Linked Clones and Composer* Instant Clones (available in all desktop SKUs)
Persistent Disks* and Persona Management DEM Standard/Enterprise and AV User Writable Volumes
Windows 7, Windows 8.1 and Server 2008 Support Windows 10 and Server 2012R2 and Newer
JMP Server Multicloud Assignments (Part of Horizon Subscription)
Horizon Administrator (FLEX/Flash Based) Horizon Console (HTML5)
ThinPrint VMware Integrated Printing
Security Server Unified Access Gateway
vRealize Operations for Horizon Cloud Monitoring Service and ControlUp Entitlement (Part of Horizon Subscription)

*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.

Integrating Rubrik Andes 5.1 with Workspace ONE Access

Early in December, Rubrik released the latest version of their core data protection platform – Andes 5.1. One of the new features in this release is support for SAML identity providers.  SAML integration provides new capabilities to service providers and large enterprises by enabling integration into enterprise networks without having to directly integrate into Active Directory.

Rubrik also supports multi-factor authentication, but the only method supported out of the box is RSA SecurID.  SAML integration enables enterprises to utilize other forms of multi-factor authentication, including RADIUS-based services and Azure MFA.  It also allows for other security policies to be implemented including device-based compliance checks.

Prerequisites

Before we can begin configuring SAML integration, there are a few things we need to do.  These prerequisites are similar to the Avi Networks SAML setup, but we won’t need to open the Workspace ONE Access metadata file in a text editor.

First, we need to make sure a DNS record is in place for our Rubrik environment.  This will be used for the fully-qualified domain name that is used when signing into our system.

Second, we need to get the Workspace One Access IDP metadata.  Rubrik does not import this automatically by providing a link the idp.xml file, so we need to download this file.  The steps for retrieving the metadata are:

  1. Log into your Workspace One Access administrator console.
  2. Go to App Catalog
  3. Click Settings
    7a. idp metadata WS1 Catalog Settings
  4. Under SaaS Apps, click SAML Metadata7b. idp metadata WS1 Catalog Settings idp
  5. Right click on Identity Provider Metadata and select Save Link As.  Save the file as idp.xml7c. idp metadata WS1 Catalog Settings idp

Rubrik SAML Configuration

Once the prerequisites are taken care of, we can start the SAML configuration on the Rubrik side.  This consists of generating the Rubrik SAML metadata and uploading the Workspace ONE metadata file.

  1. Log into your Rubrik Appliance.
  2. Go to the Gear icon in the upper right corner and select Users1. Users Menu
  3. Select Identity Providers2. Identity Providers
  4. Click Add Identity Provider3. Add Identity Providers
  5. Provide a name in the Identity Provider Name field.
  6. Click the folder icon next to the Identity Provider Metadata field.
  7. Upload the idp.xml file we saved in the last step.
  8. Select the Service Provider Host Address Option.  This can be a DNS Name or the cluster floating IP depending on your environment configuration.  For this setup, we will be doing a DNS Name.
  9. Enter the DNS name in the field.
  10. Click Download Rubrik Metadata.4. Rubrik Identity Provider Config
  11. Click Add.
  12. Open the Rubrik Metadata file in a text editor.  We will need this in the next step.

Workspace ONE Configuration

Now that the Rubrik side is configured, we need to create our Workspace ONE catalog entry.  The steps for this are:

  1. Log into your Workspace One Access administrator panel.
  2. Go to the Catalog tab.
  3. Click New to create a new App Catalog entry.
  4. Provide a name for the new Rubrik entry in the App Catalog.
  5. If you have an icon to use, click Select File and upload the icon for the application.
    5. New SaaS Application
  6. Click Next.
  7. In the Authentication Type field, select SAML 2.0
  8. In Configuration, select URL/XML
    6. SaaS Configuration 1
  9. Copy the contents of the Rubrik Metadata XML file.
  10. Paste them into the URL/XML textbox.
  11. Scroll down to the Advanced Properties section.
  12. Expand Advanced Properties.
  13. Click the toggle switch under Sign Assertion
    7. Sign Assertion
  14. Click Next.
  15. Select an Access Policy to use for this application. This will determine the rules used for authentication and access to the application.
    16. Assign Access Policy
  16. Click Next.
  17. Review the Summary of the Configuration
  18. Click Save and Assign
  19. Select the users or groups that will have access to this application
  20. Click Save.

Authorizing SAML Users in Rubrik

The final configuration step is to authorize Workspace ONE users within Rubrik and assign them to a role.  This step only works with individual users.  While testing, I couldn’t find a way to have it accept users based on a group or SAML attribute.

The steps for authorizing Workspace ONE users is:

  1. Log into your Rubrik Appliance.
  2. Go to the Gear icon in the upper right corner and select Users1. Users Menu
  3. Select Users and Groups8. Users and Groups
  4. Click Grant Authorization9. Grant Authorization
  5. Select the directory.
    10. Select Directory
  6. Select User and enter the username that the user will use when signing into Workspace ONE.11. Enter Username
  7. Click Continue.
  8. Select the role to assign to the user and click Assign.12. Assign Rights
  9. The SAML user has been authorized to access the Rubrik appliance through SSO.

Testing SAML Authentication and Troubleshooting

So now that we have our authentication profiles configured in both Rubrik and Workspace One Access, we need to test it to ensure our admin users can sign in.  In order to test access, you need to sign out of your Rubrik appliance.  When you return to the login screen, you’ll see that it has changed slightly, and there will be a large “Sign in with SSO” button above the username field.  When pressed, users will be directed to Workspace ONE and authenticated.

While Rubrik may be listed in the Workspace ONE Access App Catalog, launching from the app catalog will just bring you to the login page.  I could not figure out how to get IdP-initiated logins to work, and some of my testing resulted in error pages that showed metadata errors.

Integrating Microsoft Azure MFA with VMware Unified Access Gateway 3.8

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:

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.
    1. Enterprise AD-Updated
  4. Click New Application.
    2. New Enterprise Application-Updated
  5. Select Non-Gallery Application.
    3. Non-Gallery Application
  6. Give the new application a name.
    4. Enterprise Application 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
    5. Assign Users and Groups
  9. Click Add User
    5a. Add Users
  10. Click where it says Users and Groups – None Selected.
    5b. Select Users
  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.
    5c. Return to main menu
  14. Click 2. Set up single sign on.
    6. Configure SSO
  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.
    8. Basic 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
      9. Basic SAML Configuration URLS
  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.
    10. Download Metadata URL 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.
    11. Identity Provider Metadata
  5. Leave the Entity ID field blank.  This will be generated from the metadata file you upload.
  6. Click Select.
    12. Select IDP Metadata file
  7. Browse to the path where the Azure metadata file you downloaded in the last section is stored.  Select it and click Open.
    13. Select XML File Updated
  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.
    14. Save IDP Data-Updated
  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
      15. Select MFA Configuration
  14. Select the identity provider that will be used.  For Azure MFA, this will be the one labeled https://sts.windows.net
    16. Select Identity Provider
  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.