Horizon View

Installing the Horizon View Agent on a Domain Controller

03/09/2017 by William Lam Leave a Comment

A couple of weeks back, a fellow colleague needed to install the Horizon View Agent on a Microsoft Windows Domain Controller to be able to take advantage of the Direct Connect feature to efficiently connect into a lab environment. In general, this is not a recommended practice. In fact, by default the Horizon View Agent includes several pre-checks, one of which that prevents the installation if it detects the underlining system is a Domain Controller.

In this particular scenario, the Domain Controller was not being used for a real production environment but rather as part of a vPod that is hosted in a Hands-On-Lab type of environment. I could also see another use case where this might occur in personal home labs where you might consolidate several types of roles on a single Windows system and wish to be able to use the Direct Connect feature of the Horizon View Client.

The individual had searched extensively online but all the suggested command-line flags were not applicable to the Horizon View Agent. After pinging me for ideas, I reached out to a few of our End-User Computing folks and thanks to them, we found a neat little work around by tweaking the MSI installer.

Disclaimer: This is not officially supported by VMware, please use at your own risk. There are no guarantees that the behavior described here will continue to function going forward and it can change without notice.

How to bootstrap Horizon View 5.3.1 onto a VSAN Datastore using VCT

03/14/2014 by William Lam 2 Comments

As some of you may have heard, vSphere 5.5 Update 1 including the much anticipated VMware Virtual SAN (VSAN) was released earlier this week. To take advantage of this new vSphere release, other VMware solutions were also updated including the latest Horizon View 5.3.1 which now supports VSAN. Having spent some time playing around with the recent VMware Fling VCT which I have written about here and here, I thought why not give the latest version a try? I really like the simplicity of the VCT appliance which allows you to easily deploy an entire Horizon View environment from scratch and it just requires a stand-alone ESXi host not managed by vCenter Server and a Window 2008 ISO. Out of the box, VCT only supports vSphere 5.5 and Horizon View 5.3, but you can easily tweak either the HTML pages or modify the POST request to deploy the latest version of VCSA and Horizon View/Composer.

Since Horizon View 5.3.1 supports VSAN, I thought it would be neat to be able to "bootstrap" the entire Horizon View environment onto a VSAN datastore which would allow you to consume all the underlying physical disks without having to resort to a "temporary" VMFS volume to deploy the additional infrastructure. Now of course, this assumes you have no existing infrastructure or if you want to quickly spin up a POC or testing environment for View. The diagram above illustrates what the environment will look like at the end.

Below are the instructions for leveraging VCT to automate the deployment of vCenter Server Appliance 5.5 Update 1 and Horizon View 5.3.1

Step 1 - Install ESXi 5.5 Update 1 on your physical ESXi host or even virtual (which is how I tested this configuration)

Step 2 - Configure VSAN datastore on your single ESXi node using the "bootstrap" instructions here

Step 2 - Download VMware VCT & Studio and follow the optimized deployment here and deploy onto the VSAN datastore in previous step

Step 3 - Download VCSA 5.5 Update 1 & Horizon View 5.3.1, download links can be found here

Step 4 - Upload the three files to the VCT appliance via SCP and store them in /installers directory

Step 5 - If you plan on automating the Horizon View deployment from the command line, you will need the automateVCT.sh script and modify the following variables so they look like the following:

VIEW_SERVER_BIN=VMware-viewconnectionserver-x86_64-5.3.1-1634134.exe
VIEW_COMPOSER_BIN=VMware-viewcomposer-5.3.1-1634135.exe
VCSA_OVA=VMware-vCenter-Server-Appliance-5.5.0.10000-1624811_OVF10.ova

If you plan on using the VCT UI to deploy your Horizon View environment, then you will need to edit the following HTML files and either append or replace the VCSA OVA / View filenames

/apache-tomcat-7.0.27/webapps/vct/existing.html
/apache-tomcat-7.0.27/webapps/vct/new.html

Once the files have been uploaded, you will then be able to run through VCT as you normally would and in an hour or so, you should have a fully deployed VCSA 5.5 Update 1 and Horizon View 5.3.1 environment up and running on top of a VSAN datastore.

Once your initial ESXi host is configured, you can then deploy your other ESXi hosts and add them to your VSAN Cluster. Remember, you should have at least a minimum of 3 nodes with a recommendation of 4 as pointed out by Duncan Epping in his blog article here. From what I can tell, VCT had no issues provisioning VCSA 5.5 Update 1, there were no major changes and the same goes for Horizon View 5.3.1. I was even able to add in my vCenter Server to ensure basic View functionality was working.

I think this is a great way if you want to quickly setup a vSphere 5.5 Update 1 environment and evaluate the latest Horizon View 5.3.1 release. I also came across this Horizon View 5.3.1 on VMware Virtual SAN - Quick Start Guide KB that will also come in handy if you are looking to use Horizon View with VSAN.

Automating Horizon View deployments using VCT & cURL

03/11/2014 by William Lam 1 Comment

Last week I spent a couple of days playing around with the new Horizon View Configuration Tool (VCT) Fling and as part of my "exploration" of VCT, I needed to re-run the deployment. Going through the guided wizard the first time was fine, but if you needed to do that 5-10 times, then it was not very fun. Since VCT was a simple web application, I decided to fire up one of my favorite tool, Firebug to do some poking around.

It turns out the payload request was actually very simple and it contains all the variables for each of the parameters that a user would specify through the UI and a single HTTP POST request is then sent to the web application for deployment. I took all the variables and created a simple shell script that a user can easily edit without having to worry about fat-fingering on the UI as there is no form validation at the moment and then send the POST request using my other favorite tool cURL.

Disclaimer: These scripts are provided for informational and educational purposes only. It should be thoroughly tested before attempting to use in a production environment.

You can download the script here called automateVCT.sh

Before running the script, you will need to edit the variables for your environment and if you have an existing Active Directory server, then there are some variables that you can leave off. Towards the bottom of the script, there is an infinite loop that will run to continuously to check the current status which is then printed on the screen every 10 seconds. For practical use, you will probably want to change the timing to something a bit longer like every 5 minutes for a status.

Here is an example of executing the script:

As you can see from the screenshot, once the request has been accepted by VCT, the status will be printed on the screen which is the same status shown in the UI. If everything was successful, you should eventually see the status display the IP Address of your Horizon View environment like the following:

This script really came in handy for testing VCT and I thought it would be great to share it with the community so you can automate the deployment of your Horizon View environment using VCT!

Horizon View in a box using new Horizon View Config Tool

03/07/2014 by William Lam 1 Comment

The folks over at VMware Labs have really been on fire lately. Last week, they help release another exciting new Fling called Horizon View Configuration Tool. This latest Fling, also known as VCT was developed by Marilyn Basanta, who works over in our EUC organization. Marilyn's goal for this first release of VCT was simple, to enable customers to easily and quickly deploy a basic Horizon View 5.3 environment from scratch. I had the chance to meet up with Marilyn this week in person to discuss some of my feedback regarding VCT and something that really stood out to me was that she really understood the importance of Automation. If you compare this to the manual approach today, which has many moving parts not to mention the learning curve for new VMware customers , you can see why a solution like VCT would be a valuable tool for our customers.

After VCT was announced, I knew I had to give this a spin in my home lab! After quickly glancing at the documentation, I deployed VCT and found a couple of interesting tidbits that you should be aware of before getting started.

In addition to deploying VCT, you will need to also deploy the VMware Studio virtual appliance which is used to provision Windows OSes
A standalone ESXi host that is not managed by vCenter Server
All virtual machines provisioned by VCT are "Zeroed Thick" and not Thin (minus VCT/Studio as you can specify)
At least 19GB of memory is required, not including desktops you would provision

I went through a "full" VCT deployment in my home lab which I also included an Active Directory instance and here are the resource requirements for each Virtual Machine which I know some folks were interested in:

VM	vCPU	vMEM	vDISK	DISK TYPE
View Config Tool	1	512 MB	14 GB	THIN
VMware Studio	1	512 MB	50 GB	THIN
Active Directory	2	2 GB	16 GB	ZEROED THICK
VCSA	2	8 GB	125 GB	ZEROED THICK
Horizon View	2	4 GB	20 GB	ZEROED THICK
Horizon Composer	2	4 GB	20 GB	ZEROED THICK

For a first release where a user can just provide a Windows Server 2008 ISO and specify a couple of parameters and just sit back and watch this entire environment provision automatically is very impressive. However, I thought what would be even cooler is if we can further reduce the barrier for customers to try out this awesome tool. I did a bit of digging around in the VCT appliance and found that there are a couple of "tweaks" err "hacks" that you could perform to help reduce the footprint of your Horizon View setup.

Disclaimer: These optimizations is something that I spoke to Marilyn about and among other things and she is well aware of some of these early limitations which hopefully will be addressed in future releases of VCT.

For optimization #1 and #2, you will need to perform this before you start the VCT wizard. For optimization #3, this can be done after your Horizon View environment is up and running

Optimization # 1 - Enable "Thin" provisioning of VCSA

SSH to your VCT appliance and edit the following file /apache-tomcat-7.0.27/webapps/vct/WEB-INF/classes/deploy_vCenter.py and ensure it looks like the below (changes highlighted in blue):

deploy_vm = ["/ovftool/ovftool", "-n=" + name, "-ds=" + datastore, "-dm=thin", "-nw=" + network, "--acceptAllEulas", "--noSSLVerify", vcenter_path, "vi://" + esx_username + ":" + esx_password + "@" + esx_host ]

Optimization # 2 - Enable "Thin" provisioning for Windows VMs (View, Composer & AD)

SSH to your VCT appliance and edit the following file /apache-tomcat-7.0.27/webapps/vct/WEB-INF/classes/deploy_ova_studio.py and ensure it looks like the below (changes highlighted in blue):

ssh_command = "sh /opt/vmware/share/ovftool/ovftool --name=\"" + name + "\" --datastore=\"" + datastore + "\" -dm=thin --network=\"" + network + "\" " + path + " vi://" + esx_username + ":" + esx_password + "@" + esx_host

Optimization # 3 - Reduce VCSA memory

For a small environments or POCs, you can run VCSA with 4GB of memory. The default from VMware is 8GB, but this is not the minimal and will depend on the size of your environment (# of VMs/Hosts).

With these simple modifications, you can significantly reduce the amount of storage required and more importantly reduce the amount of memory down to ~14GB if not more due to other memory saving techniques such as VMware TPS. If you already have an existing Active Directory server, you can even further reduce it. The primary reason I was interested in reducing the resource requirements (which I am always a fan of) is that I wanted to demonstrate that you could easily get a fully working Horizon View environment running on top of an Apple Mac Mini! How cool is that!? I mean anyone can be walking around with a Mac Mini that includes everything to run or demo a full Horizon View 5.3 environment. The deployment in my environment took about ~3hrs, I suspect it was slow due to my spinning rust and it should be much faster on an SSD. I was also able to get away with just needing 91.8 GB of storage (all powered on) for the base infrastructure, of course you should allocate a bit more if you want to actually deploy additional desktops.

I highly recommend those of you who are interested in Horizon View to give VCT a try and if you have any feedback or features you would like to see, please leave a comment on the Flings webpage. I know Marilyn is very interested in hearing customer feedback and how she and her team can better improve VCT in the future. Great job again Marilyn, very cool solution and glad to see there is no shortage of innovation at VMware!

Quick Tip – Connecting to multiple View Brokers using Horizion View Client on Mac OS X

10/30/2013 by William Lam 1 Comment

On a regular basis, I will remote into at least 3 to 4 different lab environments where desktops are serviced through different Horizon View brokers. Being within VMware R&D, I get to work on a variety of projects and that means I need to jump in and out of an environment for development, troubleshooting, reproduction, etc. I recently upgraded my View Client 1.3 (before the name change) to the latest Horizon View Client which is now 2.1 and to my surprise I found that I could no longer simultaneously connect to multiple desktops from different View brokers. I have been using this feature for quite some time and I was just surprised to see it gone.

For those of you who have not used this before, you used to be able to create "New Connection" while being connected to a desktop as seen in the screenshot below.

In the latest Horizon View Client, this option is now grayed out.

One new feature that was added in the latest version of the Horizon View Client is the ability to connect to multiple desktops from the same View broker which can come handy. However, for my particular use case this is a set back and disconnecting/reconnecting is just not ideal, especially when I know I need to context switch between two desktops.

A workaround that would allow you to connect to different desktops from different View brokers is to launch the first instance of Horizion View Client from the launch pad. Once the first instance is running, you will then need to open a terminal and run the following command which will launch additional instances of the Horizon View Client:

"/Applications/VMware Horizon View Client.app/Contents/MacOS/vmware-view"

I have been told this feature was removed in the 1.4 release of View Client due to some performance issues found in Mac OS X RDP sessions. I hope this will eventually be fixed as it was a really nice feature to have. For now, you will need to use the work around if you need to connect to multiple View brokers. For myself personally, I have decided to downgrade back to version 1.3 release, unfortunately this build is no longer available for public download.