Horizon View 5.3 Part 13 – VMware Blast

One of the new features that was introduced in Horizon View 5.2 was VMware Blast.  VMware Blast gives Horizon View administrators another option for allowing users to access virtual desktops – any HTML5 compatible web browser.

Yes.  You read that right.  The newest option for accessing virtual desktops is your web browser.  There are a couple of good use cases for this – employee remote access, employee BYOD,  and Internet or guest-use kiosks are the first three that come to mind. 

But there are also some drawbacks.  A number of features, such as multimedia redirection, virtual printing (ThinPrint), and USB device access, are not available through Blast.  View Blast is not as scalable as PCoIP – a single connection server can only support 350 users when using Blast compared to 2000 users when using PCoIP.

Despite those drawbacks, this is one of my favorite features.  I love the ability to log into a desktop without having to load the View Client onto a machine.

Unfortunately, this feature isn’t included in the default installation, and additional components need to be installed on connection servers and virtual desktops in order to enable it. 

Enabling VMware Blast

There are two components that need to be installed to allow HTML desktop access in a Horizon View environment.  One component, the Horizon View HTML Access component, needs to be installed on connection servers, and Horizon View Remote Experience Agent needs to be installed on the View desktop with the HTML component enabled.  No additional components need to be installed on Security Servers, but a service will need to be enabled to allow the Security Server to manage HTML5 connections to desktops.

Connection Server

The steps for installing the HTML Access component on a Connection Server are:

1. Run the HTML Access Installer


2. Click Next


3. Accept the license agreement and click Next


4.  Select the installation directory and click Next


5. Click Install to begin the installation


6. Once the installation has finished, click Finish to exit the installer.


After you have installed the HTML access component, you will want to ensure that the VMware Blast firewall rules are enabled, and you can do that in the Firewall Management Console. 

Firewall - VMware Blast
Caption: Make sure the two highlighted rules are enabled.

Security Server

The VMware View Blast Secure Gateway Service is the Blast component that runs on View Security Servers.  This components is part of the default security server installation, but the service is disabled.

If you are using a security server and plan to allow HTML access to external users, you will need to make sure the VMware View Blast Secure Gateway Service is set to Automatic and started.   You will also need to enable the VMware Blast firewall rules.

View Desktop Agents

A component will need to be installed on each desktop that you want to enable HTML access to.  This component is part of the Horizon View Remote Experience Agent.

The steps for installing the agent are:

1. Run the Horizon View 5.3 Remote Experience Agent installer.


2. Accept the license agreement.


3.  The HTML Access option is enabled by default.  Click next to continue.


4. Click Install. 

All the components that are required for HTML Access will be installed after this installation is complete.  If you are planning to use this feature with Linked Clones, you will need to take a snapshot and recompose the desktop pools where you want to use this feature.

Configuring VMware Blast URLs

The URLs that will be used to access desktops through VMware Blast need to be configured before users can log in.  These URLs are configured in View Administrator, and they can be configured on both Connection Servers and Security Servers.

The procedure for configuring the URLs are the same for Connection Servers and Security Servers.  These steps are:

  1. Log into View Administrator
  2. Click on View Configuration
  3. Click on Servers
  4. Click on the Connection Servers or Security Servers tab.
  5. Select the server that you want to configure and click Edit.
  6. Enter the URL that users will use for accessing desktops via HTTPS under Blast Secure Gateway.  The default port for Blast is 8443.



Enabling HTML Access for Desktop Pools

Although the components for HTML Access are installed, the feature isn’t turned on yet.  Users will not be able to access their desktops through a web browser until this feature is enabled on a desktop pool.

The steps to enable HTML Access are:

  1. Log into View Administrator
  2. Click on Pools
  3. Select the pool you want to enable HTML Access for
  4. Click Edit
  5. Click the Pool Settings tab
  6. Look for the line called HTML Access in the Remote Display Protocol section.  Check the box for Enabled and click OK.


Accessing Desktops over HTML

Once HTML Access is enabled, you can log into your desktop right away.  The login URL for VMware Blast is the similar as the URL used for the Blast Secure Gateway.  The only difference is the port that users will connect to, the login page is a regular HTTPS site.

For example, if the URL you choose for your Blast Secure Gateway is https://blast.homedomain.com:8443, users should be directed to https://blast.homedomain.com to log in.  If they go to the former example, they will receive an error page that “missing route token in request.” 

That’s All, Folks!

That covers the basics of setting up HTML access to View Desktops with VMware Blast.  Despite missing a number of features that the View Client has, this is a great tool for providing access to virtual desktops without having to install the desktop client.

Top Virtualization Blog Voting For 2014 Now Open

Every year,  Eric Siebert (Twitter: @ericsiebert) of vsphere-land.com runs a poll of the top VMware and virtualization blogs.  The poll to select the top virtualization blogs for 2014 is now open.  You can vote here.

Eric’s poll is a great way to recognize the top bloggers in the field.

This will be the first year that this blog will be participating in the poll.  Unfortunately, there isn’t a category for top end user computing/virtual desktop blog, but if you enjoy what you’ve seen so far, feel free to vote for me in the general category.

Windows 8.1 Win-X Menu and Roaming Profiles

One of the features of the new version of Horizon View 5.3 is support for Windows 8.1, and I used this as my desktop OS of choice as I’ve worked through installing View in my home lab.  After all, why not test the latest version of a desktop platform with the latest supported version of Microsoft Windows.

Like all new OSes, it has its share of issues.  Although I’m not sure that anyone is looking to do a widespread deployment of 8.1 just yet, there is an issue that could possibly hold up any deployment if roaming profiles are needed.

When Microsoft replaced the Start Menu with Metro in Windows 8, they kept something similar to the old Start menu that could be accessed by pressing Win+X.  This menu, shown below, retained a layout that was similar to the start menu and could be used to access various systems management utilities that were hidden by Metro.


The folder for the WinX menu is stored in the local appdata section of the Windows 8.1 user profile, so it isn’t included as part of the roaming profile.  Normally this wouldn’t be a big deal, but there seems to be a bug that doesn’t recreate this folder on login for users with roaming profiles.

While this doesn’t “break” Windows, it does make it inconvenient for power users. 

This won’t be an issue for persistent VDI environments where the user always gets the same desktop or where roaming profiles aren’t used.  However, it could pose some issues to non-persistent VDI environments.

Unfortunately, there aren’t many alternatives to roaming profiles on Windows 8.1.  Unlike the old Start Menu, there is no option to use folder redirection on the WinX folder.  VMware’s Persona Management doesn’t support this version of Windows yet, and even though the installer allows it as an option, it doesn’t actually install.  If Persona Management was supported, this issue could be resolved by turning on the feature to roam the local appdata folder.

The current version of Liquidware Labs’ ProfileUnity product does provide beta support for Windows 8.1, but I haven’t tried it in my lab yet to see how ProfileUnity works with 8.1.

The last option, and the one that many end users would probably appreciate, is to move away from the Metro-style interface entirely with a program like Start8 or Classic Shell.  These programs replace the Metro Start Menu with the classic Start Menu from earlier versions of Windows. 

I’ve used Classic Shell in my lab.  It’s an open source program that is available for free, and it includes ADMX files for managing the application via group policy.  It also works with roaming profiles, and it might be a good way to move forward with Windows 8/8.1 without having to retrain users.

Looking for New Home Lab Storage

I’ve been a fan of Nexenta for a long time.  I’m not sure if it was Sun’s ZFS file system, the easy-to-use web interface, or how Nexenta was able to keep up with my changing needs as my lab grew and acquired more advanced gear.  Or it was support for VAAI.  Whatever the reason, or combination of reasons, Nexenta was a core component in my lab.

That changed a few months ago when I started a series of upgrades that culminated in my storage moving to a new server.  During those upgrades, I came across a few issues that forced me to change to OmniOS and NAPP-IT as a short-term solution while waiting to see if a new version of Nexenta was released.

Nexenta is no longer viable as a storage platform in my lab because:

  • Version doesn’t play nicely with the Broadcom NICs in the Dell PowerEdge T310 that I use for storage due to a line being commented out in the driver.  Even when I fix this, it’s not quite right.
  • Version 3.1.5 didn’t work period when I had USB devices plugged in – which makes it hard to use when you have USB hard drives and a USB keyboard.
  • Version 4 is vaporware.

The OmniOS/Napp-IT combination works, but it doesn’t meet one of my core requirements – VAAI support.

It doesn’t seem like a new version of Nexenta Community Edition will be coming anytime soon.  A beta was supposed to be released early in January, but that hasn’t materialized, and it’s time to move onto a new platform.

My requirements are fairly simple.  My requirements are:

  1. Spouse Approval Factor – My wife is 7 months pregnant and wants to buy a house.  Any solution must be either open-source or extremely cheap.  The less I spend, the better.
  2. Support for Fibre Channel – I’ve started putting 4GB Fibre Channel in as my storage network.  The solution must have support for using Fibre Channel as I would prefer to keep using it for my storage network.
  3. VMware APIs for Array Integration – My home lab is almost entirely virtualized, so any solution must support VAAI.

ZFS isn’t a requirement for a new system, and I’m not worried about performance right now.  A web interface is preferred but not required.

If you have any recommendations, please leave it in the comments.

Horizon View 5.3 Appendix D – Pool Settings

In Part 12, I went over how to create an automatic linked clone pool.  One area I quickly glossed over was what the options on the Pool Settings page were and what they controlled.  When setting up your desktop pools, it is important to understand what these options control.

The settings are grouped into four categories: General, Remote Settings, Remote Display Protocol, and Adobe Flash Settings.  General provides options for logins.  Remote Settings handles general desktop behavior for the pool.  Remote display protocol controls options for the display settings in the pool, and Adobe Flash Settings controls how Adobe Flash is managed. 

General Settings

There are two options in the General settings section.  These two options are:

State: State controls whether users can log into the pool or not.  If the pool is set to enabled, entitled users can log in.  If it is disabled, entitled users cannot log in.

Connection Server Restrictions: Horizon View allows Connection Servers to be tagged or grouped.  These tags can be used to control which connection servers can be used to access a pool.  For instance, if you had connection servers tagged Internal and External, you can use the tags to ensure that a pool used by Accounting cannot be accessed from Internet-facing connection servers.


Remote Settings

Remote Settings is an odd name for this group, and it probably should be renamed Pool Settings or merged with general.  This group of settings controls desktop power behavior, logon behavior, and idle session duration.

Remote Desktop Power Policy: This setting controls how the power-state of desktops are managed after the user logs off or the desktop is no longer being used as a spare. The options are:

Take No Power Action: If this option is selected, View will not change the power state after a user logs out or the desktop is no longer needed.  Powered on desktops will remain powered on and desktops that are shut down will remain shut down.

Suspend: Desktops that are no longer needed will be suspended by vCenter instead of shut down. 

Power Off: The desktop is shut down and powered off after the user logs off or the desktop is no longer needed as a spare.

Ensure Desktops are Always Powered On: The desktop is always powered on, even when it is not needed.

More information on these options can be found here.

Automatically Log Off After Disconnect: This setting determines how long a session will remain in a disconnected or idle state before the user is logged out.  The options are:

Never: This is the default option.  Users will remain logged in but disconnected indefinitely.

Immediately: The session will be immediately logged out after disconnection.

After X Minutes: The session will remain disconnected for a length of time determined by the administrator before the session is logged out.

Allow Users to Reset Their Desktop: This setting, if enabled and set to Yes, allows users to reset their desktop manually to a known good setting.

Allow Multiple Sessions Per User: This setting controls whether users are allowed to have multiple concurrent sessions in a pool. 

Delete or Refresh Desktop on Logoff: This setting controls what happens to the virtual desktop after the user logs off.  The options are:

Never: Nothing happens to the desktop after logoff, and it may go into an ‘Already Used’ state.

Delete Immediately: The desktop is deleted from the environment and recreated from scratch.  The VM-ID of the desktop changes with this operation.

Refresh Immediately: The desktop is rolled back to the last good snapshot, but it is not deleted.  The VM-ID of the desktop is not changed when this operation occurs.

Remote Display Protocol

The Remote Display Protocol section controls some of the settings that govern remote connections to the pool. 

Default Display Protocol: This setting controls the default protocol that is used between the virtual desktop and the client.  The two options are PCoIP and Microsoft RDP. 

This isn’t the only place that display settings are configured.  Fine-grained control over the PCoIP protocol is done via Group Policy through the included ADM files on the Connection Server.

Allow users to choose protocol: If this is set to yes, the user can change the protocol when logging into the pool.  If set to no, the user will always use the default protocol.

3D Renderer: If the pool is using a desktop built on Windows 7 or newer, PCoIP is the default protocol, and the user is not allowed to choose the protocol, 3D rendering settings can be configured for the pool.  Hardware, software, and automatic are the options that can be selected, and the amount of video memory can be configured as well.

Max Number of Monitors: The maximum number of monitors that users will be able to utilize when logging into their virtual desktop when using PCoIP.  The default is 2, but four monitors can be supported as well.  This setting, along with Max Resolution, is used to determine video RAM if 3D Rendering is disabled.

Max Resolution of any one monitor: This is the maximum screen resolution supported on any desktop when using PCoIP.  This setting, along with Max Resolution, is used to determine video RAM if 3D Rendering is disabled.

HTML Access: If the HTML Access component is installed on your connection brokers and Feature Pack 1 is installed on the desktop, you can enable HTML Access.  When this setting is enabled, users can log into the desktop pool using VMware Blast and any HTML5 compatible browser.


Adobe Flash Settings

The final group of settings that can be configured are for managing Adobe Flash.  These settings can control the quality of Flash content in order to reduce the amount of bandwidth that a virtual desktop utilizes.

The two settings that can be configured here are:

Adobe Flash Quality: This setting controls the image quality of Flash content.

Adobe Flash Throttling: This setting controls the framerate of the Flash content.  The more aggressive the setting, the lower the frame rate.

As I mentioned above, there are settings that can control image quality, bandwidth usage, and other settings inside the virtual desktop that can be set with Group Policy.  I’ll go over more details on how to do that in an upcoming appendix.