Horizon 7.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 StartSSL or a low-cost certificate provider such as NameCheap. 


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 a 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 7.0 handles certificates on the Windows Server-based components the same way as Horizon 6.x and Horizon 5.3.  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 can use 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.

If you plan to use Subject Alternate Names on your certificates, I highly recommend reviewing this article from Microsoft.  It goes over how to create a certificate request file for SAN certificates.

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.

;----------------- request.inf -----------------

Signature="$Windows NT$"


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


OID= ; this is for Server Authentication

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


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.

The command the generate the certificate request is:

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 or Security Server services.

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. 

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


Certificates and Horizon Composer

Unfortunately, Horizon Composer uses a different method of managing certificates.  Although the certificates are still stored in the Windows Certificate store, the process of replacing Composer certificates is a little more involved than just changing the friendly name.

The process for replacing or updating the Composer certificate requires a command prompt and the SVIConfig tool.  SVIConfig is the Composer command line tool.  If you’ve ever had to remove a missing or damaged desktop from your Horizon environment, you’ve used this tool.

The process for replacing the Composer certificate is:

  1. Open a command prompt as Administrator on the Composer server
  2. Change directory to your VMware Horizon Composer installation directory
    Note: The default installation directory is C:\Program Files (x86)\VMware\VMware View Composer
  3. Run the following command: sviconfig.exe –operation=replacecertificate –delete=false
  4. Select the correct certificate from the list of certificates in the Windows Certificate Store
  5. Restart the Composer Service


A Successful certificate swap

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

Access Point Certificates

Unlike Connection Servers and Composer, Horizon Access Point does not run on Windows.  It is a Linux-based virtual appliance, and it requires a different certificate management technique.  The certificate request and private key file for the Access Point should be generated with OpenSSL, and the certificate chain needs to be concatenated into a single file.  The certificate is also installed during, or shortly after, deployment using Chris Halstead’s fling or the appliance REST API. 

Because this is an optional component, I won’t go into too much detail on creating and deploying certificates for the Access Point in this section.  I will cover that in more detail in the section on deploying the Access Point appliance later in the series.

Horizon 7.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 four components to serve virtual desktops to end users: ESXi, vCenter, a View Connection Server, and Active Directory.  The hardware for this type of environment doesn’t need to be anything special, and 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 the broker for the environment.  They handle desktop provisioning, user authentication and access.  They also manage connections to multi-user desktops and published applications.   Connection Servers also manage the

There are four types of Connection Server roles, and all four 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
  • Security Server – A stripped down version of the Connection Server, designed to sit in the DMZ and proxy traffic to the Connection Servers.  A Security Server must be “paired” with a Connection Server.
  • Enrollment Server – A new role introduced in Horizon 7.  The Enrollment Server is used to facilitate the new True SSO feature.

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 2008 R2 or Windows Server 2012 R2
  • Joined to an Active Directory domain
  • Static IP Address

Note: The requirements for the  Security Server  and Enrollment Server are the same as the requirements for Connection Server.  Security Servers do not need to be joined to an Active Directory domain.

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

ESXi – ESXi is required for hosting the virtual machine The versions of ESXi that are supported by Horizon 7 can be found in the VMware compatibility matrix.  ESXi 5.0 Update 1 and newer, excluding ESXi 5.5 vanilla, are currently supported.  However, ESXi 6.0 Update 1 and newer are required for Instant Clones.

vCenter Server – The versions of vCenter that are supported by Horizon 7 can be found in the VMware compatibility matrix.  vCenter Server 5.0 Update 1 and newer, excluding vCenter 5.5 vanilla, are currently supported, and vCenter 6.0 Update 1 and newer are required to support Instant Clones.  The vCenter Server Appliance and the Windows vCenter Server application are supported.

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 2008 functional level.  Group Policy is used for configuring parts of the environment, including desktop settings, roaming profiles, user data redirection, UEM, and the remoting protocol.   

Advanced Features

Horizon View 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 linked-clone desktops.

Secure Remote Access – There are a couple of options for providing secure remote access to virtual desktops and published applications.  Traditionally, remote access has been provided by the Horizon Security Server.  The Security Server is a stripped down version of the connection server that is designed to be deployed into a DMZ.  It also requires each server to be paired with a Connection Server.

There are two other remote access options.  The first is the Horizon Access Point.  The access point comes from the Horizon Air platform, and it was introduced in the on-premises solution in Horizon 6.2.2.  The Access Point is a hardened Linux appliance that is designed to be managed like a cloud appliance, and it serves the same function as the Security Server.  Unlike the Security Server, the Access Point does not need to be paired with a Connection Server.

Both the Security Server and the Access Point can be load balanced for high availability.

The other remote access option is the Horizon proxy built into the F5 APM module.  The APM module combines load balancing and rule-based secure remote access.  It can also replace the portal feature in vIDM.

Linked-Clone Desktops – Linked Clones are virtual machines that share a set of parent disks.  They are ideal for some virtual desktop environments because they can provide a large number of desktops without having to invest in new storage technologies, and they can reduce the amount of work that IT needs to do to maintain the environment.  Linked Clones are enabled by Horizon Composer.

The requirements for Horizon Composer are:

  • 2 vCPUs, 4 vCPUs recommended 
  • 4 GB RAM, 8GB required for deployments of 50 or more desktops
  • Windows Server 2008 R2 or Server 2012 R2
  • Database server – supported databases include Oracle and Microsoft SQL Server.  Please check the compatibility matrix for specific versions and service packs.
  • Static IP Address

Horizon Composer also requires a database.  The database requirements can be found in the VMware Product Interoperability Matrix.  The current requirements include SQL Server 2014 (RTM and SP1), SQL Server 2012 (SP2) and Oracle 12c Release 1.

Networking Requirements – Horizon requires a number of ports to be opened to allow the various components of the infrastructure to communicate.  The best source for showing all of the ports required by the various components is the VMware Horizon 7 Network Ports diagram.  It’s available in PDF format from here.

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, User Environment Manager, VMware Identity Manager (vIDM), and vRealize Operations for Horizon.  The requirements for these tools will be covered in their respective sections.

Horizon 7.0 Part 1–Introduction

I realize that this series might seem like it’s a little late.  After all, Horizon 7.0 has been out for a few months now.  But between a very large writing project and wanting to take a few weeks off from writing, it’s time to get started with the comprehensive Horizon 7.0 series.

There have been a lot of updates and new features added to Horizon 7.0, and I covered most of those updates in a post back in February after the initial Horizon 7 announcement.  The major features are:

  • Instant Clones – New Provisioning Method
  • Blast Extreme – New Remoting Protocol
  • UEM Smart Policies – New Context Aware Policy Management

Those are just what I consider the major features that will impact most deployments.  There are a lot of other improvements as well, including improvements to scalability through CloudPod, security through True SSO, and new client redirection features to support additional use cases.

Unlike my previous series, I plan to go beyond installing the core Horizon 7.0 components.  This year, I hope to cover Access Point, RDSH, UEM, vRealize Operations for Horizon, and the latest version of App Volumes.  No, that won’t be App Volumes 3.0.  But I could cover that too.

Stay tuned.  There will be much more to come.

It’s Time To Reconsider My Thoughts on GPUs in VDI…

Last year, I wrote that it was too early to consider GPUs for general VDI use and that they  should be reserved only for VDI use cases where they are absolutely required.  There were a number of reasons for this including user density per GPU, lack of monitoring and vMotion, and economics.  That lead to a Frontline Chatter podcast discussing this topic in more depth with industry expert Thomas Poppelgaard.

When I wrote that post, I said that there would be a day when GPUs would make sense for all VDI deployments.  That day is coming soon.  There is a killer app that will greatly benefit all users (in certain cases) who have access to a GPU.

Last week, I got to spend some time out at NVIDIA’s Headquarters in Santa Clara taking part in NVIDIA GRID Days.  GRID Days was a two day event interacting with the senior management of NVIDIA’s GRID product line along with briefings on the current and future technology in GRID.

Disclosure: NVIDIA paid for my travel, lodging, and some of my meals while I was out in Santa Clara.  This has not influenced the content of this post.

The killer app that will drive GPU adoption in VDI environments is Blast Extreme.  Blast Extreme is the new protocol being introduced in VMware Horizon 7 that utilizes H.264 as the codec for the desktop experience.  The benefit of using H.264 over other codecs is that many devices include hardware for encoding and decoding H.264 streams.  This includes almost every video card made in the last decade.

So what does this have to do with VDI?

When a user is logged into a virtual desktop or is using a published application on an RDSH server, the desktop and applications that they’re interacting with are being rendered, captured, encoded, or converted into a stream of data, and then transported over the network to the client.  Normally, this encoding happens in software and uses CPU cycles.  (PCoIP has hardware offload in the form of APEX cards, but these only handle the encoding phase, rendering happens somewhere else…

When GPUs are available to virtual desktops or RDSH/XenApp servers, the rendering and encoding tasks can be pushed into the GPU where dedicated and optimized hardware can take over these tasks.  This reduces the amount of CPU overhead on each desktop, and it can lead to snappier user experience.  NVIDIA’s testing has also shown that Blast Extreme with GPU offload uses less bandwidth and has lower latency compared to PCoIP.

Note: These aren’t my numbers, and I haven’t had a chance to validate these finding in my lab.  When Horizon 7 is released, I plan to do similar testing of my own comparing PCoIP and Blast Extreme in both LAN and WAN environment.

If I use Blast Extreme, and I install GRID cards in my hosts, I gain two tangible user experience benefits.  Users now have access to a GPU, which many applications, especially Microsoft Office and most web browsers, tap into for processing and rendering.  And they gain the benefits of using that same GPU to encode the H.264 streams that Blast Extreme uses, potentially lowering the bandwidth and latency of their session.  This, overall, translates into significant improvements in their virtual desktop and published applications experience*.

Many of the limitations of vGPU still exist.  There is no vMotion support, and performance analytics are not fully exposed to the guest OS.  But density has improved significantly with the new M6 and M60 cards.  So while it may not be cost effective to retrofit GPUs into existing Horizon deployments, GPUs are now worth considering for new Horizon 7 deployments.

*Caveat: If users are on a high latency network connection, or if the connection has a lot of contention, you may have different results.

What’s New – Horizon 7.0

(Edit: Updated to include a Blast Extreme feature I missed.)

Last week, VMware announced App Volumes 3.0.  It was a taste of the bigger announcements to come in today’s Digital Enterprise event.  And they have a huge announcement.  Just a few short months after unveiling Horizon 6.2, VMware has managed to put together another major Horizon release.  Horizon 7.0 brings some significant enhancements and new features to the end-user computing space, including one long awaiting feature.

Before I talk about the new features, I highly recommend that you register for VMware’s Digital Enterprise event if you have not done so yet.  They will be covering a lot of the features of the new Horizon Suite offerings in the webinar.  You can register are http://www.vmware.com/digitalenterprise?src=sc_569fec388f2c9&cid=70134000000Nz2D.

So without further ado, let’s talk about Horizon 7’s new features.

Instant Clones

Instant Clones were debutted during the Day 2 Keynote at VMworld 2014.  After receiving a lot of hype as the future of desktop provisioning, they kind of faded into the background for a while.  I’m pleased to announce that Horizon 7 will feature Instant Clones as a new desktop provisioning method.

Instant Clones utilize VMware’s vmFork technology to rapidly provision desktop virtual machines from a running and quiesced parent virtual desktop.  Instant clones share both the memory and the disk of the parent virtual machine, and this technology can provide customized and domain joined desktops quickly as they are needed.  These desktops are destroyed when the user logs off, and if a new desktop is needed, it will be cloned from the parent when requested by a user.  Instant clones also enable administrators to create elastic pools that can expand or shrink the number of available desktops based on demand.

Although they might not be suited for all use cases, there are a couple of benefits to using instant clones over linked clones.  These are:

  • Faster provisioning – Instant Clones provision in seconds compared to minutes for linked clones
  • No Boot Storms – The parent desktop is powered on, and all instant clones are created in a powered-on state
  • Simplified Administration – No need to perform refresh or recompose operations to maintain desktops.
  • No need to use View Composer

Although instant clones were not available as a feature in Horizon 6.2, it was possible to test out some of the concepts behind the technology using the PowerCLI extensions fling.  Although I can’t validate all of the points above, my experiences after playing with the fling show that provisioning is significantly faster and boot storms are avoided.

There are some limitations to instant clones in this release.  These limitations may preclude them from being used in some environments today.  These limitations are:

  • RDSH servers are not currently supported
  • Floating desktop pools only.  No support for dedicated assignment pools.
  • 2000 desktops maximum
  • Single vCenter and single vLAN only
  • Limited 3D support – no support for vGPU or vDGA, limited support for sVGA.
  • VSAN or VMFS datastores only.  NFS is not supported.

Desktop personalization for instant clones is handled using App Volumes User Writable drives and UEM.

Blast Extreme

VMware introduced HTML5 desktop access using the Blast protocol in Horizon 5.2 back in 2013.  This provided another method for accessing virtual desktops and, later, published applications.  But it had a few deficiencies as well – it used port 8443, was feature limited compared to PCoIP, and was not very bandwidth efficient.

The latest version of Horizon adds a new protocol for desktop access – Blast Extreme.  Blast Extreme is a new protocol that is built to provide better multimedia experiences while using less bandwidth to deliver the content.  It is optimized for mobile devices and can provide better battery life compared to the existing Horizon protocols.


Most importantly, Blast Extreme has feature parity with PCoIP.  It supports all of the options and features available today including client drive redirection, USB, unified communications, and local printing.

Unlike the original Blast, Blast Extreme is not strictly a web-only protocol.  It can be used with the new Windows, MacOS, Linux and mobile device clients, and it works over port the standard HTTPS port.  This simplifies access and allows users to access it in many locations where ports 8443 and 8172 are blocked.

Blast Extreme is a dual-stack protocol.  That means that it will work over both TCP and UDP.  UDP is the preferred communications method, but if that is not available, it will fall back to TCP-based connections.

Smart Policies

What if your use case calls for disabling copy and paste or local printing when uses log in from home?  Or what if you want to apply a different PCoIP profile based on the branch office users are connecting to?  In previous versions of Horizon, this would require a different pool for each use case with configurations handled either in the base image or Group Policy.  This could be cumbersome to set up and administer.

Horizon 7 introduces Smart Policies.  Smart policies utilize the UEM console to create a set of policies to control the desktop behavior based on a number of factors including the groups that the user is a member of and location, and they are evaluated and applied whenever a user logs in or reconnects.  Smart policies can control a number of capabilities of the desktop including client drive redirection, Clipboard redirection, and printing, and they can also control or restrict which applications can be run.

Enhanced 3D Support

Horizon 6.1 introduced vGPU and improved the support for workloads that require 3D acceleration.  vGPU is limited, however, to NVIDIA GRID GPUs.

Horizon 7 includes expanded support for 3D graphics acceleration, and customers are no longer restricted to NVIDIA.  AMD S7150 series cards are supported in a multi-user vDGA configuration that appears to be very similar to vGPU.  Intel Iris Pro GPUs are also supported for vDGA on a 1:1 basis.

Cloud Pod Architecture

Cloud Pod Architecture has been expanded to support 10 Horizon pods in four sites.  This enables up to 50,000 user sessions.

Entitlement support has also been expanded – home site assignment can be set for nested AD security groups.

Other enhancements include improved failover support to automatically redirect users to available resources in other sites if they are not available in the preferred site and full integration with vIDM.

Other Enhancements

Other enhancements in Horizon 7 include:

  • Unified Management Console for App Volumes, UEM, and monitoring.  The new management console also includes a REST API to support automating management tasks.
  • A new SSO service that integrates vIDM, Horizon, Active Directory, and a certificate authority.
  • Improvements to the Access Point appliance.
  • Improved printer performance
  • Scanner and Serial redirection support for Windows 10
  • URL Content redirection
  • Flash Redirection (Tech Preview)
  • Scaled Resolution for Windows Clients with high DPI displays
  • HTML Access 4.0 – Supports Linux, Safari on IOS, and F5 APM


Horizon 7 provides another leap in Horizon’s capabilities, and VMware continues to reach parity or exceed the feature sets of their competition.

Horizon EUC Access Point Configuration Script

Horizon 6.2 included a new feature when it was launched in early September – the EUC Access Gateway.  This product is a hardened Linux appliance that has all of the features of the Security Server without the drawbacks of having to deploy Windows Servers into your DMZ.  It will also eventually support Horizon Workspace/VMware Identity Manager.

This new Horizon component exposes the “cattle philosophy” of virtual machine management.  If it stops working properly, or a new version comes out, its to be disposed of and redeployed.  To facilitate this, the appliance is configured and managed using a REST API.

Unfortunately, working with this REST API isn’t exactly user friendly, especially if you’re only deploying one or two of these appliances.  This API is also the only way to manage the appliance, and it does not have a VAMI interface or SSH access.

I’ve put together a PowerShell script that simplifies and automates the configuration of the EUC Access Gateway Appliances.  You can download the script off of my Github site.

The script has the following functions:

  • Get the appliance’s current Horizon View configuration
  • Set the appliance’s Horizon View configuration
  • Download the log bundle for troubleshooting

There are also placeholder parameters for configuring vIDM (which will be supported in future releases) and uploading SSL certificates.

The syntax for this script’s main features look like:

Set-EUCGateway -appliancename -adminpassword P@ssw0rd -GetViewConfig

Set-EUCGateway -appliancename -adminpassword P@ssw0rd -SetViewConfig -ViewEnablePCoIP -ViewPCoIPExternalIP $ViewDisableBlast

Set-EUCGateway -appliancename -adminpassword P@ssw0rd -GetLogBundle -LogBundleFolder c:\temp

If you have any issues deploying a config, use the script to download a log bundle and open the admin.log file.  This file will tell you what configuration element was rejected.

I want to point out one troubleshooting note that my testers and I both experienced when developing this script.  The REST API does not work until an admin password is set on the appliance.  One thing we discovered is that there were times when the password would not be set despite one being provided during the deployment.  If this happens, the script will fail when you try to get a config, set a config, or download the log bundle.

When this happens, you either need to delete the appliance and redeploy it or log into the appliance through the vSphere console and manually set the admin password.

Finally, I’d like to thank Andrew Morgan and Jarian Gibson for helping test this script and providing feedback that greatly improved the final product.

What’s New in VMware Horizon 6.2–User Experience

One of the areas where Horizon 6.2 has a lot of improvements is in the User Experience category.  The new version adds new features as well as brings a few older features out of tech preview.

Client Drive Redirection for VDI and RDSH

Client Drive redirection for Windows was in Tech Preview in Horizon 6.1.1.  It officially comes out of Tech Preview in Horizon 6.2, and it is now supported on both Windows and Mac clients.  It is also available as a tech preview for Linux clients.

This feature, when installed on the virtual desktop, allows users to remotely access files and data that might have stored on their local PC.  It utilizes compression and encryption when transferring files from the endpoint into the virtual desktop or server. 

Windows 10 Support

Although Windows 10 was officially supported on vSphere 6 on Day 1, it wasn’t supported in Horizon.  Virtual desktops built on Windows 10 would work, but there limits to what you could do, and other components of the Horizon Suite were not designed to work with or support it.

Horizon 6.2 has full support for Windows 10.  The Horizon Agent and Client are supported.  This includes Smart Card authentication support.

Windows 10 is only supported when running ESXi 5.5 Update 3 or ESXi 6.0 Update 1.

File Type Associations for Published Apps

There are times when I may want to allow a user to launch an application or work with files without installing the required applications on their machines.  In these cases, the user would then have to log into Horizon, launch the application, and then navigate to the network location where the file was stored.

But what if I could register a file handler in Windows that would allow me to double click on that file and have it launch the remote application automatically?  Horizon 6.2 now adds this capability.

In order to improve the user experience when opening files remotely, a data compression algorithm is utilized when transferring the files up to the remote host.  This transfer is also protected with SHA 256 encryption for when clients are remotely accessing the remote application over the Internet.

Mac OSX and IOS Support

Horizon Client 3.5 will be supported on OSX 10.11 and IOS 9.

Biometric Authentication

The Horizon Client for IOS will support biometric authentication.  This feature will allow users to store their credentials in Keychain and utilize their fingerprints to sign into their virtual desktops or published applications.  Administrators can also define polices for who can use this feature from with the Horizon Administrator console.

This feature is only supported with Horizon 6.2 when using Horizon Client 3.5.  The mobile device must also be running IOS 8 or IOS 9.

What’s New in VMware Horizon 6.2–3D Graphics

3D graphics are becoming increasingly important in virtual desktop environments.  While a number of high-end applications and use cases, such as CAD and medical imaging, require 3D graphics, modern applications are increasingly turning to the GPU to offload some processing.  These days, most web browsers, Microsoft Office, and even Windows are utilizing the GPU to assist with rendering and other tasks.

VMware has been slowly adding 3D support to Horizon.  Initially, this was limited to dedicating GPUs to a virtual machine or sharing the GPU through hypervisor-level components.  Horizon 6.1 added  NVIDIA’s vGPU to provide better shared GPU access.

Horizon 6.2 includes a significant number of improvements to virtual 3D acceleration.  In fact, most of the improvements are in this category.


NVIDIA announced the next generation of GRID on Sunday afternoon.  For more information, see my write-up on it here.


AMD/ATI graphics cards were supported on virtual desktops in vSphere 5.x and Horizon 5.x.  This did not carry over to Horizon 6.  AMD support has been reintroduced in Horizon 6.2 for vDGA.

3D Support for RDS Hosted Applications

RDS desktops and published applications will now support both vDGA and vGPU when utilizing supported NVIDIA graphics cards.  3D acceleration is supported on RDSH servers running Windows Server 2008 R2 and Windows Server 2012.

Linux Desktop vSGA and vGPU Support

When Linux desktops were introduced in Horizon 6.1.1, they only supported vDGA for 3D graphics.  This limited Linux to a few specific use cases.

Horizon 6.2 adds significant support for 3D acceleration.  Both vSGA and vGPU are now available when utilizing supported NVIDIA graphics cards.

Linux desktops with vGPU will be able to utilize OpenGL 2.1, 3.x, and 4.x, while desktops with vSGA will be limited to OpenGL 2.1.

4K Resolution Support

4K content is extremely high resolution content, and more 4K content will appear as the displays start to come down in price.  These displays, which have a resolution of 3840×2160, are useful in situations where high resolution imaging is needed.

Horizon 6.2 will support in-guest resolutions up to 3840×2160.  In order to achieve this, Horizon Agent 6.2 is needed in the guest, and the client must be connecting with Horizon Client 3.5.

The guest operating system must be running Windows.  A Windows 7 virtual desktop can support up to three 4K monitors when running on a VM with HW version 11 and with Aero disabled.  Windows 7 machines with Aero enabled, or Windows 8 desktops running on HW version 10 can support a single 4K monitor.

Please note that this is for in-guest display resolutions.  Clients that have a 4K display with High DPI scaling are not supported at this time.

What’s New in VMware Horizon 6.2 – RDSH and Application Publishing

Publishing applications from RDSH servers was one of the big additions to Horizon 6.0.  Horizon 6.2 greatly expands on this feature set, and it offers many new capabilities under the covers to improve the management of the environment.

Cloud Pod Support for Applications

Horizon’s Cloud Pod for multi-datacenter architectures has been expanded to include support for RDSH-published applications.  Users can now be entitled to an application once and access them across Horizon pods and/or datacenters. 


Enhanced RDSH Load Balancing

The load balancing and user placement algorithms have been enhanced in Horizon 6.2 to ensure that users do not get placed on an already overloaded server.  There are two main improvements that enable this:

1. The load balancing algorithm utilizes Perfmon counters to determine which hosts are optimal for starting new sessions.  The View agent runs a script to collect system performance data, and it reports back to the connection servers with a recommendation based on the system’s current performance.  A server placement order is calculated based on the data that the View Agents return.

2. Application anti-affinity rules will look at the number instances of an application that is running on an RDSH host.  If the number of a particular application is higher than a predefined value, user connections will be directed to another host.  Application anti-affinity rules process after the server placement order has been determined.

There are a couple of things to be aware of with the new load balancing algorithms.  First, they only apply to new sessions, so if a user already has a session on an RDSH server, they will be reconnected to that session and be able to launch any application, even if it violates an anti-affinity rule.

Application anti-affinity rules also do not apply to RDSH desktop sessions.

Linked-Clone Support and Horizon Composer for RDSH

If you had wanted to build an RDSH Farm for Horizon 6.0, you would have had to build, deploy, and manage each server manually.  There was no built-in way for managing server images or server updates.  This could also be an inefficient use of storage.

Horizon 6.2 changes this.  Composer now supports linked-clone RDSH servers.  This brings the benefits of linked-clone desktops, such as automated pool builds, single image management, and system and application consistency, to server-based computing.

What’s New in VMware Horizon 6.2–Core Infrastructure

In order to set up and run VMware Horizon, you need to have a vSphere infrastructure and Windows VMs to run the server components.  Horizon 6.2

Horizon Access Point

One of the challenges of deploying Horizon is that, in order to provide external access, you need to deploy Windows machines into your network’s DMZ.  These servers, called Security Servers, run a subset of the Connection Broker that proxies or tunnels PCOIP, Blast, and RDP connections into your environment.

Horizon Security Servers have their limitations, though.  To start with, they are usually not joined to an Active Directory domain, so they cannot be configured or managed with the Group Policies that manage the rest of your infrastructure.  Because these servers live in the DMZ, they also need to be patched frequently and secured.

Security Servers are also paired directly with a Connection Server.  If the Connection Server is not available, users who connect with that particular security server would not be able to authenticate or connect to a desktop.  This also limits the number of servers you can deploy to a maximum of seven. 

Horizon 6.2 will now include a new method of providing remote access called the Access Point.  The Access Point is a locked-down virtual appliance built on SUSE Linux Enterprise Edition 11 that has feature parity with the Security Server.  It allows you to remove Windows VMs from your DMZ, and it does not need to be paired with a Connection Server, so you can scale out your external access without having to add additional connection servers.

The Access Point will not be dedicated to Horizon View.  It is designed to work with all components of the Horizon Suite – reducing the number of external access components that you need to manage.


One-Way Trust Support

If you work in a multi-domain or federated environment, Horizon View required a two-way trust between domains or forests in order to authenticate and entitle users.

There are a number of environments where two-way trusts aren’t feasible.  Think about companies that routinely undergo mergers, acquisitions, or divestitures.  They have use cases for virtual desktop environments, but a two-way trust between Active Directory environments would pose security and integration challenges.

Horizon 6.2 takes a step towards resolving this by adding support for 1-way Active Directory trusts.  Users and groups from external (trusted) domains can now be granted access to Horizon desktops without having to create a full two-way trust.


In order to fully support one-way forest trusts, Horizon will need to utilize a service account with permissions to authenticate against the trusted domain.  This account is stored in the Horizon LDAP database, and all of its credentials are encrypted.

Secondary credentials are managed by using the vdmadmin command line tool that is installed on Connection Servers.

vSphere 6 Update 1 Support

Horizon 6.2 will support vSphere 6 Update 1 on Day 1.

FIPS and Common Criteria Certification

The US Federal Government has a number of criteria that IT products must meet.  These include things like IPv6 compatibility, FIPS cryptographic support, and Common Criteria certification.

Horizon 6.1 introduced support for IPv6.  Horizon 6.2 expands upon this with support for FIPS on all Horizon Windows components.  FIPS will also be supported in Horizon Client 3.5 for Windows.

FIPS mode is optional, and it can be enabled if it is required.

VMware will also be submitting Horizon 6.2 for Common Criteria certification, and this testing is currently in process.  It should be completed sometime in 2016.

Enhanced License Console

The license console in previous versions of Horizon was not very detailed.  It would give you the current number of active users with a breakdown by virtual machine type.

Horizon 6.2 overhauls the licensing console on the Admin page.  The new licensing console shows part of the key that is in use along with the number of concurrent connections and unique named users that have logged in.