Horizon 7.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, which are a new option, 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 Composer.

Some Active Directory objects need to be configured before any Horizon View 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

Optionally, you may want to set up an organizational unit for any security groups that might be used for entitling access to the Horizon View 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.

CREATING AN ORGANIZATIONAL UNIT FOR HORIZON DESKTOPS

The first think that we need to do to prepare Active Directory for a Horizon deployment is to create an organizational unit structure for Horizon View desktops.  This OU structure will hold all of the desktops created and used by Horizon View.  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 Composer and/or Instant Clones Administrator service account.

There are a lot of ways that you can set up an Active Directory OU structure for Horizon.  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 Persona Management on non-persistent desktops but allow Windows Updates on the desktop templates.

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.

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 RES and VMware User 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

Horizon 6.0 added PCoIP support for multi-user desktops running on Windows Server with the Remote Desktop Session Host role.  These new abilities also added support for remote application publishing.

RDSH servers need to be handled differently than virtual desktops.  They’re managed differently than your virtual desktops, and some features such as Persona Management are not available to RDS servers.

If application remoting or multi-user desktops are going to be deployed, an organizational unit for RDS servers should be created underneath your base servers organizational unit. Since RDSH servers are often heavily locked down through Group Policy, I also recommend creating an RDSH Maintenance Mode OU.  This OU is where RDSH servers can be placed when administrators need to remove restrictive group policies such blocking the command prompt or MSI installers removed to perform maintenance on the server.

Horizon Group Policy Objects

Horizon contains a number of custom group policy objects that can be used for configuring features like Persona Management and optimizing the PCoIP protocol.  The number of Group Policy objects and templates is same as what was available in Horizon 6.

Unfortunately, most of the Group Policy templates are distributed as ADM files.  There are a number of drawbacks to ADM files in modern Active Directory environments.  The main one is that you cannot store the Group Policy files in the Central Store.

If you plan on using the Group Policy templates, it’s a good idea to convert them into the ADMX format.  I had previously written about converting the View Group Policy templates into the ADMX format and the reasons for converting here.

Horizon Service Accounts

Horizon requires a service account for accessing vCenter to provision new virtual machines.  If Horizon Composer or 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 7.0 Part 3–Desktop 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.

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.

There are four types of desktops in Horizon 7:

  • Full Clone Desktops – Each desktop is a full virtual machine deployed from a template and managed as an independent virtual machine.
  • Linked Clone Desktops – A linked clone is a desktop that shares its virtual disks with a central replica desktop, and any changes are written to its own delta disk.  Linked clones can be recomposed when the base template is updated or refreshed to a known good state at periodic intervals.  This feature requires Horizon Composer.
  • 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.

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.

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.

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

  • Number of linked clone base images and/or full clone templates
  • Number and type of desktop pools
  • Number of desktops per pool
  • Number of Connection Servers needed
  • The remote access delivery method

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.

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

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.

image

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

Thoughts

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 10.1.1.2 -adminpassword P@ssw0rd -GetViewConfig

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

Set-EUCGateway -appliancename 10.1.1.2 -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 GRID 2.0

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

vDGA for AMD GPUs

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. 

image

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.