Wednesday, December 17, 2014

How to customize the "Download Workspace for Windows" URL in Workspace Portal

If you've found yourself directing users to download the Workspace for Windows Client by telling them to login to Workspace, click their name, and choose "Download" only to find it takes them to you're not the only one!

Users should be able to download the Windows Client directly by clicking "Download"

There's even a pretty button for it!

Luckily this is pretty simple to address.

To change the Workspace Client Download URL:

  1. Login to the Workspace appliance as root, and type the following

    vi /usr/local/horizon/conf/

  2. You should see a single line that reads winSyncClientUrl=

  3. Simply change the value of winSyncClientUrl to the desired URL. You could set this to the actual VMware Download page for Workspace Products ( or you can set it to an internal link to the .exe itself on your web server. I have mine set to my cloud share for direct access to the .exe:

  4. Restart the workspace service

    service horizon-workspace restart

  5. Reload your Workspace User page and you now have a working download link for the client! Good luck!


Monday, December 15, 2014

Workspace Portal SSL Certificates [updated for vIDM]

[Updated September 2015]

The below process was originally written for Workspace Portal 2.1 and can be applied to vIDM. Any differences in process has been placed appropriately within the post.

VMware strongly recommends that you configure SSL certificates that are signed by a valid Certificate Authority (CA) for use by Workspace Portal.

A default SSL server certificate is automatically generated when the Workspace appliance is installed. Although you can use the default, self-signed certificate for testing purposes, it should be replaced as soon as possible for a production environment. The default certificate is not signed by a CA. Use of certificates that are not signed by a CA can allow untrusted parties to intercept traffic by masquerading as your server.

If you deploy Workspace with the self-signed SSL certificate, the Workspace root CA certificate must be available as a trusted CA for any client who accesses Workspace. The clients can include end user machines, load balancers, proxies, and so on. You can download the Workspace root CA from

Before you can import a certificate, you must generate a Certificate Signing Request (CSR) and obtain a valid, signed certificate from a CA. If the CSR is not generated according to the example procedure described in this document, the resulting certificate and its private key must be available in a PEM format file.

There are many ways to obtain SSL certificates from a CA. This post shows how to use OpenSSL to generate a CSR and make a certificate available to Workspace Portal. You can use another method if you are familiar with the required tools, and they are installed on your server.

If your organization provides you with SSL certificates that are signed by a CA, you can use these certificates. If these certificates are not in the necessary PEM format, you can convert them with third party tools, such as that from SSLShopper

To make a certificate available to Workspace Portal 2.1, three things must be done:

  1. Create a configuration file

  2. Generate a certificate signing request (CSR) from the configuration file

  3. Send the signing request to a CA

When the CA returns the certificate, you must import the signed certificate into Workspace Portal using the Appliance Configurator. If using a Load Balancer, you must import the signed certificate onto to the Load Balancer per the vendor's instructions, and then install the Load Balancer's Root CA Certificate on Workspace Portal.

Creating the configuration file

We will be using OpenSSL as it comes pre-installed on the Workspace Portal appliance, though you can use OpenSSL on a wide variety of operating systems, including Windows. The below instructions will be assuming a Linux based OS.

  1. Login to your system that has OpenSSL installed (if using the Workspace appliance, either open a vSphere console, or SSH into the appliance).

  2. Create a folder to perform the certificate work in:mkdir certificates
    cd certificates

  3. Copy openssl.cnf into that foldercp /etc/ssl/openssl.cnf openssl.cnf

  4. Edit the file using vi.
    vi openssl.cnf
    The part of the file you have to modify in order to generate a certificate request is highlighted below. For a wildcard certificate request, subjectAltName is not relevant.

[ req_distinguished_name ] # Change these settings for your


countryName_default = US

stateOrProvinceName_default = Colorado

localityName_default = Broomfield

0.organizationName_default = EUC

organizationalUnitName_default = IT


[ CA_defaults ] # Change sha1 to sha512

default_md = sha512


[ req ]

default_bits = 2048

[ v3_req ]

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment,


extendedKeyUsage = serverAuth, clientAuth

subjectAltName = DNS:, DNS:, DNS:, DNS: Since we will request a wildcard

certificate these additional hostnames are not of importance.

NOTE: We are not setting the commonName here, we will do that below when prompted. If you plan to not use a wildcard, consider adding your subjectAltNames

Save this file


Generating the certificate request

  1. Create your CSR and private key by typingopenssl req -new -nodes -out rui.csr -keyout rui.key -config openssl.cnf

  2. Accept the default values you configured on the .cnf file. When prompted for the common name, enter either the wildcard value, or the external name you will be referencing for Workspace from outside your network (e.g., sure you store your private key in a safe place. Without it, your certificate becomes useless.

  3. Congrats! You've successfully created a certificate signing request for a sha512 hashed, 2048-bit encrypted certificate. Now to get this CSR signed.

Send the CSR to a Certificate Authority (CA) for signing

Your CSR must be submitted to a CA in order to be issued a usable certificate. You can use either a publicly trusted CA (GoDaddy, DigiCert, etc), or an internal CA your company has, or perhaps one you even built yourself. If you don't go with a publicly trusted CA, there are plenty of options for setting up your own CA. The important thing to ensure is when you've been issued your certs, download them as Base 64 encoded.

Installing the certificate

Once you've obtained your certificate(s), it's time to put it together so that Workspace can understand it. Workspace needs the certificate to be in PEM format. PEM is a widely used format these days because of its flexibility and ease of use. PEM allows you to bundle multiple certificates into a single file which a server can read and understand. This is important for Workspace. If you need to convert the certs you received to PEM format, you can use the link provided earlier in this post, or even use OpenSSL. Workspace needs at least 2 certs (usually 3) which you should have received from your CA.

Server (host) cert
Intermediate cert(s)
Root cert

This is how we will build our PEM file, with the host cert on top, any intermediate certs in the middle, and root on the bottom:
(Your Primary SSL certificate)
(Your Intermediate certificate)
(Your Root certificate)

It's important to use a text editor like WordPad or Notepadd++ when handling these PEM files. Using something like Notepad can cause formatting issues that we certainly want to steer clear of.

Once you've built your new PEM file containing the components above, it's time to install it. If you don't have a load balancer or reverse proxy server in place, you can install this right on Workspace. This is considered terminating SSL on the Workspace Appliance.

To do this on Workspace Portal:

  1. Login to the Appliance Configurator (https://your_workspace:8443), click Install Certificate

  2. In the Terminate SSL on Workspace appliance tab, paste the complete certificate chain (what we created above) and also include the private key in its box.

  3. Save the SSL certificate.

To do this on vIDM:

  1. In the Administration Console, click Appliance Settings

  2. Click Manage Configuration and enter the admin password

  3. Click Install Certificate

  4. In the Terminate SSL on Identity Manager Appliance tab, select Custom Certificate.

If you're using a Load Balancer or Reverse Proxy, you'll need to instead install the cert on that device per the vendor's instructions. Using something like NGINX is quite simple as you simply include the cert and private key path in the configuration file (See How to Setup NGINX as a reverse proxy for Workspace Portal 2.1)

If you're using an internal CA, or otherwise a lesser known CA, it may be necessary to install the Root CA on Workspace in order for it to gain trust. Back at the Install Certificate page, click the Terminate SSL on a Load Balancer tab, and paste the PEM output of the Root CA here.

NOTE: if you've previously installed custom certs on Workspace itself, and are now trying to instead use a Load Balancer, you will need to first re-generate the self signed certs on Workspace before you'll be able to properly reconfigure the Workspace FQDN.

If you happen to use a KEMP load balancer with Workspace, you may run into issues configuring your FQDN after following the recommended SSL Certificate process. Please review Kemp's Workspace Documentation which should help get the load balancer configured properly.

Related documentation and references


Friday, December 12, 2014

How to remove your License from VMware Horizon View

Licensing Horizon View is quite simple. Grab your key, enter it into the GUI and you're off. What you  might have noticed, however, is that once you've submitted your key, it's as if you've deposited it into a black hole, never to be seen again. Per the licensing section in View Administrator (View Configuration > Product Licensing and Usage) the only information we get is which features are enabled and our expiration.

So what if you need to remove this license without replacing it? Or what if you're getting an error replacing the License and wish you could just wipe it out? The answer is quit simple and outlined below.

In order to clear your license from View:

  1. First, take a backup of the ADAM database ( by opening a command prompt on the Connection Server and type: vdmexport > vdmconfig.ldf

  2. Connect to ADAM via ADSI Edit (

  3. Expand OU=Properties, OU=Global then right click CN=License and choose Properties.

  4. Scroll down to pae-LicenseKey2, choose Edit, and remove all entries.

  5. Wait 2 minutes for ADAM to replicate to other brokers (if applicable) then go verify View is unlicensed in View Administrator. If you run into any issues, you can follow the first KB I linked above to restore the ADAM database.


Thursday, November 20, 2014

How to setup NGINX as a reverse proxy for Workspace Portal 2.1

Per Workspace Portal's installation guide,

During deployment, Workspace is set up inside the internal network. If you want to provide access to Workspace for users connecting from outside networks, you must install a load balancer, such as Apache, nginx, F5, and so on, in the DMZ.

This process is unfortunately outside of VMware's Documentation scope as every environment is different and we do not recommend a particular vendor/service over another.

NGINX, however, is a free and robust option that can at least get you up and running for your external users fairly quickly. This won't be a comprehensive how-to, but should certainly be useful in getting you started!

In this example, we'll be using Ubuntu Server 12.04 for the NGINX server. I performed a default install and enabled only the OpenSSH service during install. Once Ubuntu is installed and has the desired IP and hostname, go ahead and install nginx: sudo apt-get install nginx

Now you can configure nginx.conf to include all the reverse proxy information in a single file, however, in my setup, NGINX needs 3 things in order to work with Workspace:

  1. nginx.conf

  2. default.conf

  3. SSL Certificates

Here is a copy of what my nginx.conf looks like: /etc/nginx/nginx.conf (HUGE thanks to Tomi Vakala from vReality)

# nginx configuration file
# hws21

# User to run nginx processes as. Ensure this user exists on your system!
user hadmin;

# Worker processes
worker_processes 4;

error_log /var/log/nginx/error.log warn;
pid /var/run/;

events {
    worker_connections 1024;
    multi_accept on;
    # Use epoll on Linux, kqueue on *BSD and Mac OS X
    use epoll;

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;

    # Enable sendfile for improved performance on Linux
    sendfile on;

    # Enable nagle algorithm to buffer more data before sending
    tcp_nopush on;

    keepalive_timeout 65;

    # Setup client buffers
    client_body_buffer_size 256k;
    client_header_buffer_size 2k;

    # Enable gzip compression
    gzip             on;
    gzip_buffers     128 8k;
    gzip_min_length  512;
    gzip_proxied     any;
    gzip_types       text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
    gzip_comp_level  3;

    include /etc/nginx/conf.d/*.conf;

# eof

Next, we need to configure the default.conf which we told nginx.conf to include toward the end of the file.

The default.conf  (/etc/nginx/conf.d/default.conf)  you'll create and customize for your environment. The things you'll need to customize are:

  1. server_name (this is the public facing FQDN)

  2. ssl_certificate (your certificate's full chain)

  3. ssl_certificate_key

  4. proxy_pass (what nginx is proxying to - the internal Workspace instance name)

  5. [Updated] proxy_redirect off;
    -- I originally missed number 5 here in my config and it caused issues when enabling Kerberos in my environment. More on proxy_redirect here


# /etc/nginx/conf.d/default.conf

# hws2.1


server {

    # IPv4 listen directive, enable SSL

    listen 443 ssl;


    server_name workspace.vcloud.local;


    server_tokens off;


    # Strict Transport Security (HSTS), force browser to use encrypted

    # connection to this site at all times

    add_header Strict-Transport-Security "max-age=31536000;";


    # Configure SSL

    ssl on;

    ssl_certificate /etc/ssl/workspace_chain.crt;

    ssl_certificate_key /etc/ssl/workspace.key;

    ssl_session_cache shared:SSL:50m;

    ssl_session_timeout 10m;

    ssl_prefer_server_ciphers on;

    # Set list of preferred ciphers to enable use of ciphers with perfect

    # forward secrecy to improve security



    # Reverse proxy directives

    location / {

        proxy_pass https://hws21.vcloud.local:443/;
        proxy_redirect off;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_read_timeout 1800;

        proxy_connect_timeout 1800;

        proxy_http_version 1.1;

        proxy_max_temp_file_size 5m;


        # Increase proxy memory buffers

        proxy_buffering on;

        proxy_buffer_size 32k;

        proxy_buffers 16 32k;

        proxy_busy_buffers_size 32k;




# eof


If you're not much of an SSL wizard, the following two links will be extremely useful in setting up an internal CA with openSSL, then generating your internally signed certs (assuming you don't have Third Party CA signed certs)

Once default.conf and nginx.conf have been configured, and your certificate is valid, you should be able to start nginx. If the service fails to start, it should indicate which component it's having an issue with, whether it's one of the .conf files themselves, or the provided certificate or key file.

The next steps would be to then login to the Workspace Configurator portal at https://:8443/cfg/setup

Click on Install Certificate > Terminate SSL on a Load Balancer. Here you can install the root CA cert from the Load Balancer. Then under Workspace FQDN you can set your new public FQDN.

If you have issues changing your FQDN, check out this excellent troubleshooting blog on VMware Blogs

Good luck!


Saturday, November 1, 2014

How I built a budget gaming PC for under $400

I had a goal this past year to build a budget gaming PC. Obviously everyone has different budget constraints, but my goal was to keep it under $400 which I was able to accomplish.

Here were my other goals for this system:
  1. Something with plenty of storage, but not overkill
  2. Decent boot times since it likely wouldn't be powered on 24/7
  3. Decent gaming experience without an expensive GPU
  4. Something I could also rely on for working from home

After lots of research to accomplish these goals for cheap, I decided to build an AMD box. AMD vs Intel is an age-old battle that I honestly don't care for.. I've mostly used Intel my whole life, but I can tell you that I'm quite satisfied with my AMD's performance. Most people can agree that AMD is an excellent choice for boxes on a budget.

When researching how to get decent gaming performance without throwing my whole budget at a GPU, I discovered the AMD APU (Accelerated Processing Unit). I took a chance on this CPU with an integrated GPU and have been pleasantly surprised! So on to the system specs..

CPUAMD A10 6800k$129.99
MemoryG.Skill Ripjaw X 8GB$84.99
MoboMSI A78m-E35$59.99

Hard DriveSeagate Hybrid Drive ST1000DX001 1TB$96
CaseAntech Mini P1800
PSUThermaltake TR2 TR-600$24.99 (with rebate)

I also had a 10% off coupon from Newegg that I applied to my mobo/memory purchase taking an additional $15 off the price. All in all, this system only set me back ~$380

Now to be fair, I did get an excellent computer case for free. It was an item a friend of mine had laying around collecting dust that he donated to my cause. However if you were to buy a new case, a quality one would certainly put you over the $400 mark.

Of my 4 goals listed above, the first two were solved by getting the Seagate SSHD. This 1TB harddrive is plenty of space for storing a good number of games, and the small SSD portion of the drive allows for incredibly fast boot times. All in all a great deal for a budget system.

Goal #3 was met by the magic of the APU. You can find all sorts of benchmarks and reviews of the AMD APU series, but my experience has been nothing but positive. The first game I loaded up and played was Batman: Arkham Asylum which I was able to play at max settings without any hindrance at full 1080p. The entire game was an absolute joy to play (especially for a Batman nerd like myself).

Moving on to Arkham City, well, I had to lower the resolution to a windowed 1600 x 900. This still allowed for high settings to be applied, so it looks great. For hard core gamers, this is a deal breaker. But hey, if you're hard core you're probably not interested in a budget gaming rig. For me, this is perfectly acceptable. Same video config needed for Injustice: Gods Among Us. Portal and Portal 2 can both be played with high settings, no issues.

One important note of caution: these kinds of results are possible due to the memory I specifically picked out. The memory is 8GB clocked at 2133Mhz. If you want to game on an APU, you must (MUST) get the fastest RAM you can afford. 2133 is what my mobo supports and what kept the memory reasonably priced. The RAM you decide to get will make or break your choice to use the APU.

Looks a little light in there, but it does the trick! The box has plenty of room for expanding in the future. I plan to get a full on SSD and another TB or two of spinning disk drives. Plus there's enough room for a large GPU if I ever decide it's worth dumping money into.

And there you have it. Simple yet satisfying! You can find me on Steam under the username phiredrop >> Add me on Steam <<

Thursday, October 2, 2014

How to patch Shellshock in Workspace Portal

VMware has released official bash patches for Horizon Workspace and Workspace Portal to address the recently discovered shellshock bug.

Be sure to review as you must apply the correct patch for your exact version of Workspace.

How to tell if your Workspace instance is currently vulnerable

To test, run the following command on each VM in the appliance:

env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

A system vulnerable to shellshock will show output similar to this:

Here is how you can patch your Workspace servers:

  1. Head over to and select your current version of Workspace. in this example, we'll be using Workspace Portal 2.1

  2. Download the listed RPM update at the bottom of the page

  3. Copy the downloaded patch to /tmp on your Workspace VM (use something like SCP or WinSCP to accomplish this). If you are on an earlier Workspace instance with multiple VMs in the Workspace appliance, you'll need to do this on all the VMs.

  4. Login to the Workspace VM as root, and unzip the patch

  5. Change directory to the unzipped folder, and apply the patch by running
    rpm -U --nodeps *.rpm

  6. Run the test command from above again to verify you aren't still vulnerable



Friday, September 12, 2014

How to tell who deleted your Horizon View VM

It's happened to all of us - we go to find a particular desktop in the View Inventory only to find it's not there. You didn't delete, so who did?

Luckily we know better than to survey our co-workers - we can confirm from the logs!

On the Connection Server, navigate to C:\ProgramData\VMware\VDM\logs and check out the DEBUG logs.

Typically you will see a line similar to:

2014-09-11T10:45:18.210-07:00 DEBUG (0B1C-0B47) [ws_TomcatService] STDOUT: 2014-08-11 10:45:18 [com.vmware.vdi.desktopcontroller.PendingOperation]-[DEBUG] Pool floating::Stopping & deleting VM /EUC/vm/Floating/Win7-01.

In this example, if you trace the session ID (0B1C-0B47), you'll also find a line earlier in the log such as:

2014-08-11T10:39:23.053-07:00 DEBUG (0B1C-0B38) [ws_TomcatService] STDOUT: 2014-09-11 10:39:23 [com.vmware.vdi.admin.ui.LoginBean]-[INFO] User ryan has successfully authenticated to View Administrator

And voila! User ryan has been busted.

Thursday, September 11, 2014

Running Workspace Portal 2.1 in VMware Workstation 10

With the release of Workspace Portal 2.1, the vApp has been reduced to a single VM providing simpler deployment and administration. [See my post What's New in Workspace Portal 2.1] This also means it's extremely easy to run inside of VMware Workstation or Fusion. In this post, we'll be covering how to import Workspace Portal 2.1 into VMware Workstation.
Why would you want to run Workspace Portal in a desktop solution like Workstation?

Well it's by no means a production solution. It does provide a decent lab environment at best though! This is great for tinkering with the product before implementing in a vSphere environment. You can get a pretty good idea for how the product flows. If you happen to have a more advanced home lab setup in Workstation already (With Active Directory, vCenter Server, etc). If you don't, luckily there is a Demo User Store that can be selected during the Web GUI configuration which will create dummy accounts for you and use an embedded OpenLDAP instance on the VM. Pretty cool!

More info on using the Demo User Store here

To install Workspace Portal 2.1 in Workstation:

  1. Download the Workspace Portal 2.1 OVA

  2. In Workstation, choose File > Open

  3. Configure your desired Name and Location, and choose Import

  4. Review the details of the VM

  5. Power on the VM, and you'll run through the Setup Wizard

    1. Choose [1] for a complete installation

    2. Enter [y] to accept

    3. Next configure your hostname, DNS, and IP settings

    4. When done, hit [q] to continue, then [y] to confirm

  6. After it performs its initial boot and configuration, you'll see the familiar Login screen with an IP address.

    NOTE: in this example, we're using a Bridged network connection. This can be verified and configured under VM > Settings > Network Adapter

  7. In my setup, I want to be able to access Workspace with the hostname I provided earlier in the setup. In order to do that, I need to modify my computer's /etc/hosts file. My daily OS is Linux Mint, so I will perform this via the command line:

    1. First ensure you can ping the appliance from the IP listed in the console window

    2. Then add an entry for the appliance in the hosts file
      vi /etc/hostsThe entry should follow this format:
      FQDN shortname

      e.g., workspace21.mycomputer.local workspace21

  8. Once your hosts file is updated, you should be able to ping the appliance by the name you gave it.

  9. Final step is to open a browser and login per the console window's instructions!

Next Steps: Run through the web GUI to further configure the appliance. See my post on Installing/Configuring Workspace Portal


Tuesday, September 9, 2014

Installing VMware Workspace Portal 2.1

The Workspace vApp design and deployment has been dramatically simplified in this release. If you've dabbled with Workspace in the past, got frustrated with the vApp complexity, and ended up putting it on the shelf - now's the time to revisit this amazing product.

Some things that make Workspace Portal 2.1 easier to deploy than previous releases:

  1. Single VM - Workspace is now a singular VM handling all its services. No more SSHing to other VMs within the vApp and messing with proxy over and over.

  2. No more IP Pools - the requirement of IP Pools is a thing of the past. Hooray!

  3. No more vCenter dependency - deployment doesn't require vCenter URL and credentials

  4. Much faster deployment - the vApp deploys with 4 VMDKs by default and takes much less time than previous instances.

NOTE: Older instances of Workspace cannot be upgraded to Workspace Portal 2.1. Instead, a migration is required. Please see the Migration Guide here:  And see my post covering this process (coming soon)


  1. Deploy the OVA like normal (In vCenter, File > Deploy OVF Template)

    1. In the Properties section of the deployment, Ensure "Connector Only Install" remains UNchecked.

    2. Set your correct timezone settings (this will affect vApp time and log times)

    3. Opt in/out of the Customer Experience Program

    4. If you don't want to rely on DHCP, enter the FQDN, Default Gateway, DNS, IP, and Netmask for the appliance.

  2. Once the vApp is deployed, power it on. You'll be greeted with familiar instructions to navigate to your Workspace Portal's URL for configuration

  3. Once you're there, you'll see a new configuration wizard

  4. Notice you can now configure separate passwords for root, sshuser, and your administrator accounts

  5. New in the Map User Attributes page is an attribute for DaaS (Desktone), the distinguishedName

  6. Once setup is complete, it will link you to the Admin Dashboard!


What's New in VMware Workspace Portal 2.1

VMware's Workspace Portal was just brought to version 2.1. This release comes with some exciting changes and new features that make this the best Workspace release yet.

Simplified Deployment - Workspace is now a single VM (still deployed as an OVA). This architectural change makes SO MANY things easier including log locations, configuration changes (like Proxy settings), and much more. The single Connector-va service within the vApp is capable to handle most AD environments. Additional instances can be cloned for high availability and unique domain configurations.

Another handy tidbit is that (finally!) the Bind DN account used during deployment to perform the initial user sync will be added/synced itself by default. Hooray!

AirWatch and Desktone integration - AirWatch 7.3 and Desktone 6.1 can be fully integrated with SSO using Workspace Portal 2.1

All new Dashboard with reporting  - I might be the most excited about this one. Out of the box, the new Admin Dashboard shows incredibly useful reporting data such as user engagement, historical trends, system health, and active users. I'm happy to report that this dashboard also dynamically updates - no need for manual refresh (not pointing fingers... Horizon View...)

Also new is the Administrative Service Links (aka, QuickLinks). Going to https://:8443 will take you to a shortcuts page to perform administrative tasks like configure SSL certificates, administer user entitlements, and manage user authentication.

Related Posts:

Upgrading Workspace Portal 2.1 [Coming Soon]

Wednesday, August 6, 2014

Plex Server, Virtual Machines, and Google Chromecast

Recently I discovered Plex and its many wonderful capabilities. In looking for an easier way to get my media to my non-smart TV, I found a cheap solution that works extremely well. Now my home setup is not that extravagant. I have a simple Windows 8.1 box. 8GB of RAM, A10 6800k APU, AMD Radeon 7900 series GTX 960 Superclocked GPU and plenty of storage. If you're like me and have a simple setup, all you need are the following components:

  • Google Chromecast (or similar)
  • VMware Workstation (or similar)
  • A library of media

    Note: exploring the features/capabilities of Plex is outside the scope of this post.
In VMware Workstation, I use a Linux Mint VM to run my Plex server. Your server doesn't have to be Linux, so simply grab the appropriate install from the Plex Downloads.

All my media is on my host machine (the Windows 8.1 box) in my normal Library locations. What this means is that for the Plex server to be able to serve up media, it needs access to those locations. This is easily done in Workstation by adding shared folders in the VM options.

Another thing to note.. if you want to be able to access your media from outside the VM itself, you'll need the proper networking configuration to do that. With this particular setup, the easiest option is to Bridge your network connection. This simply connects the VM to the same network as your Host machine (more here). No further router configuration should be needed. You shouldn't have to tweak your network much further unless you are using something like double NAT. If you find yourself having issues loading the library later on, check out Plex's Troubleshooting page.

One last setting is needed. On your Plex server, launch the Plex Media Manager (localhost:32400/web/index.html) and go to Settings > Server > Connect and follow the prompts to connect your server to Plex. Once done, you can start adding your media into Plex by having it share your Library locations. If you used shared folders like I did, your Library will be in a location similar to /mnt/hgfs/

You should now be able to access your media from any device, on or off your home network. 

Now to get this media to your non-smart TV. This is where Chromecast comes in. For $35, you can order one of these from Amazon and have easy access to your entire Plex library on your TV (and much more including Netflix, Hulu Plus, etc). The catch is you'll need to 'cast' to it either from your PC, or mobile device. The easiest option is probably a mobile device/tablet.

The Plex app for my iPhone pictured above is, unfortunately, not free. But it's worth the $5! Once your Chromecast is plugged into the TV, and connected to your home network, you'll be able to launch Plex on your mobile device, tap the 'Cast' button, and voila! Your Plex library is now available to your TV.

If you found this post helpful, let me know in the comments!

Friday, August 1, 2014

Accessing Horizon Workspace Gateway-va URL fails with HTTP 404 Error


  • HTTP 404 Error accessing gateway

  • Service-va logs show something similar to Setting up Message Broker connection failed: Connection refused

  • Running df -h on the service-va shows /db as full



The internal Postgres Database is full and must be expanded. This article does not apply to Workspace implementations that have an external database configured.





To resolve this issue, add a new, large VMDK to the service-va and copy the contents from the old disk to the new one. This process works on service-va VMs with and without internet access.

  1. Take a snapshot of the service-va

  2. Power off the Workspace vApp

  3. Add a VMDK to the service-va

    3a. Right click the service-va and choose Edit Settings > Add > Hard Disk and choose Create new virtual disk
    3b. Ensure the new disk is at least 30GB in size

  4. Power on the service-va VM only and login as root

  5. Change to run level 1

    init 1

    5a. Verify you are in Run Level 1 by typing who -r

  6. Determine the name of the new disk (e.g., /dev/sdxx)

    fdisk -l

  7. Format the new disk with default parameters

    fdisk /dev/sdxx
    n (for new partition)
    p (for primary partition)
    Press Enter to accept Partition Number Default
    w (to write changes)

  8. Unmount /db (first take note of the device name, e.g., /dev/sdb1)

    umount /db

  9. Copy the contents of /db (in this example, /dev/sdb1) to the new partition

    dd if=/dev/sdb1 of=/dev/sdxx bs=1024

    NOTE: This copy operation may take a long time

  10. Resize the filesystem using resize2fs

    e2fsck -f /dev/sdxx
    resize2fs /dev/sdxx

  11. Mount /dev/sdb1 to /db

    mount /dev/sdb1 /db

  12. Update /etc/fstab to reflect the new partition mounted at /db

  13. Run this command to shutdown the service-va 

    shutdown -h now

  14. Power on the Workspace vApp.

    NOTE: be sure to commit the snapshot previously taken after verifying the environment is stable


Wednesday, May 21, 2014

Working with Horizon Workspace Virtual Users and zmprov

One nifty feature of Horizon Workspace is the ability to share files and folders with external users. An "external user" could mean one of two things:

  1. A directory server user not synced to Horizon Workspace

  2. Someone outside of the enterprise

An invited user is then created as a virtual user in the Workspace instance. You can find more information about virtual users in the Horizon Workspace Administrator's Guide under User and Group Types:

When a virtual user is created, they are assigned to a hidden Class of Service (COS) called defaultExternal. This class of service comes with its own parameters, notably, all virtual users are defaulted to a file upload size of 2GB. You may notice the following error when a virtual user tries to upload a file larger than 2GB:

exceeds single file maximum upload size 2147483648 bytes

Additionally, the virtual user will share the quota of the internal user that shared the file with them. So if the inviter has an unlimited quota, files the invitee uploads won't have a negative impact. Conversely, if the inviter has a 10GB limit, any file the invitee uploads will go toward that internal user's 10GB quota.

So how can we increase the virtual user's file upload size limit?

Though the defaultExternal COS is hidden in the Administration Console, you can still configure its attributes via the data-va command line.

To change the upload file size limit for virtual users:

  1. Login to the data-va as root

  2. Change to the zimbra user:

    sudo su - zimbra

  3. Switch to the virtual user tenant and modify the upload attribute to the desired file size limit, in bytes:
    $ zmprov
    prov> st __virtual__
    prov> mc defaultExternal hzndataFileUploadMaxSize filesize-in-bytes
    prov> mc defaultExternal hzndataFileUploadMaxSizePerFile filesize-in-bytes
    prov> quit

    Increasing virtual user file upload limit to 3GB

  4. Restart the service

    zmcontrol restart

Note: to clear the Tenant specifier back to default, use the unsetTenant command:

$ zmprov

prov> ut

To view all COS, you can use 'gac.' Notice my example below doesn't show defaultExternal because I do not have any virtual users:

Additionally you can run "zmprov gac -v" which will show all the configured attributes for each COS. The process outlined above can be used to edit any COS manually. Keep in mind a COS you've created in the Administrator Console GUI will be in the default tentant, not the __virtual__ tenant.

Happy modding!

Thursday, May 15, 2014

Logging into Horizon Workspace fails: We were unable to authenticate you

This error can be pesky as it is a bit misleading. The full error will read something similar to
We were unable to authenticate you. Please check your credentials and try again.

Furthermore, you may notice whenever you load the Workspace login page a notice at the top that reads
Identity provider's url scheme mismatches with that of the request. This could happen when the request is received on https and the Identity provider's is running on http.

This behavior is usually caused by our IdP trying to use port 443 but SSL authentication is disabled. To resolve this issue:

  1. Login to the connector-va web page

  2. Click on Identity Providers

  3. Verify the IdP hostname is correct and using port 443

  4. Check the box to Use SSL for end-user authentication

  5. Click Save



Give that user's login another go and you should be on your way.

Monday, April 21, 2014

Horizon Workspace 1.8.1 and Heartbleed patch

This day and age marks a great new release bound to get techies everywhere a mouth watering treat (no not that one). VMware released a patch for Horizon Workspace bringing the software to version 1.8.1!

Among numerous enhancements and fixes, this patch also includes an update to OpenSSL 1.0.1g which resolves the widespread vulnerability known as the Heartbleed Bug. You can check out the list of fixes in the Release Notes

Alongside this patch, you can apply a Heartbleed-only patch to your vApp if desired. If you're running Horizon Workspace 1.0, you must upgrade to at least version 1.5 to apply the Heartbleed fix manually. Likewise you can apply the Heartbleed fix to Workspace 1.8.0, but if you're taking the time to patch it, you might as well update to 1.8.1. See more info about that patch here:

Applying the Heartbleed-Only fix (updating OpenSSL)

Applying the Heartbleed-only patch from the above KB, you should copy the RPM to somewhere on the Gateway-va (/tmp for example). I like to use WinSCP for copying files to and from my appliances. Then run the RPM and you will see it stop nginx and apply the patch:

You can always check the status of nginx afterward by running /etc/rc.d/nginx status


Per the KB, after running the OpenSSL fix you'll want to regenerate your SSL Certs. The steps are slightly different if you terminate SSL at the gateway-va vs a Load Balancer, so be sure to refer to the article.


You can find more details on the Heartbleed vulnerability here:



Updating Workspace 1.8.0 to 1.8.1
Be sure to check out the Release Notes

1. Take a snapshot of each appliance and the external DB VM
2. Login to the Configurator as root
3. Run /usr/local/horizon/lib/menu/updatemgr.hzn check and ensure you see the 1.8.1 update, then run /usr/local/horizon/lib/menu/updatemgr.hzn update
4.  Reboot the vApp.
NOTE: If you didn't apply the Heartbleed-specific patch above prior to updating to 1.8.1, then you must generate new SSL Certs and apply them to your gateway-va. See the post-installation steps outlined in

<Screenshots coming soon>

Don't forget to also upgrade your Workspace Clients to 1.8.1!

If you have further queries or concerns about how Heartbleed could affect your Horizon View environment, take a gander at  along with the VMware Security Advisories page.

Friday, April 18, 2014

Horizon Workspace 1.8.1 Client Update & Heartbleed bug

Last night VMware quietly released a patched Windows and OSX Client for Horizon Workspace 1.5 and 1.8 bringing the client to version 1.8.1. This client release includes an updated OpenSSL 1.0.1g. Alongside the release is a KB with the remediation steps for the Client regarding the pesky CVE-2014-0160 vulnerability.

You can continue to track the VMware advisory for this vulnerability here:

Get the downloads from the VMware Product Page.

Wednesday, April 9, 2014

Horizon 6 Announced

If you weren't able to attend the live webcast of the Horizon 6 announcement this morning, keep an eye on Twitter's @vmwarehorizon account for a link to watch it later.

Horizon 6 is the latest big news from VMware and is all the buzz for EUC land. There are a number of new features and capabilities that make this a very exciting release. Check out VMware's CTO announcement of it here:

Sumit Dhawan, VP and GM of Desktop Products at VMware, frontlined the event and claimed Horizon 6 as an "Innovation Packed Release."

Horizon 6 will come in 3 flavors of licensing:

  1. View Standard - Simple, powerful VDI with great user experience
  2. Horizon Advanced - Cost-effective delivery of desktops and apps through a unified workspace
  3. Horizon Enterprise - Desktops and apps delivered with cloud automation and management
You can find more info in the Horizon 6 FAQ

Friday, March 14, 2014

Offline upgrades available for Horizon Workspace 1.8

Whether you're running Horizon Workspace 1.5 as a POC, or you restricted it to have internal access by design, admins who deployed Workspace without internet access can rejoice knowing that version 1.8 introduces a method for performing an "offline" upgrade. This option was not previously available when upgrading from 1.0 to 1.5.

The process includes setting up a local web server and using the updatelocal.hzn checkurl command against the web server.

When going through the upgrade guide, you may be wondering where you actually get the mentioned files. It's not clearly stated, however, you will need to contact VMware GSS Support in order to obtain those update bits.

Wednesday, March 12, 2014

Horizon Workspace 1.8 is out!

As you may have heard, Horizon Workspace 1.8 became GA yesterday. This release hasn't been publicized too much but is a major improvement over the 1.5 release with many bug fixes. Some of the major changes include:
  • Citrix-based Application integration. From the Horizon Workspace User Portal, users can launch Citrix-based applications via XenApp 5.0, 6.0, and 6.5 using single sign-on. Note: Citrix Receiver must be installed on the client.
  • VMware ThinApp package delivery to Windows desktops. Horizon Workspace provides delivery of ThinApp 5.0 packages with 32-bit/64-bit applications to all Windows devices. HTTP delivery is supported to non-domain member endpoints on Windows devices.
  • Microsoft Office 365. Single sign-on from Workspace to Microsoft Office 365, SharePoint, and Outlook 365 web applications. Browser based and native email clients are supported.
  • Horizon Workspace User Portal and App Center. The User Portal has been enhanced to make application resource management easier. The App Center provides users with self-service category filtering, which shows the latest applications added.
  • Web application links. IT administrators can now create Web application links that do not require user authentication, allowing administrators to create static Web links.
  • Enterprise enhancements, including the following.
  • Support for multi-forest Active Directory deployments. You can integrate Horizon Workspace with multiple Active Directory (AD) forests.
  • Application access policy. IT administrators can apply access policies and select different authentication methods based on application type.
  • Support for enterprise branding of Horizon Workspace.
  • VMware Switch enhancements, including the following.
  • Support for Android 4.2 (JellyBean) as the workspace operating system.
  • Support for Android tablets.
  • Enhanced Horizon Mail 1.7x.

You can find the release notes here:
And all other documentation here:

Remember to join our Horizon Workspace Google+ page to share tips, tricks, and help build the Workspace community!

Thursday, March 6, 2014

What's compatible with Horizon View 5.3?

I'll bet you didn't know this existed!

Have you been wondering what's compatible with Horizon View 5.3 only to find documentation on VMware's website for View 5.2? There's a reason for that...

Horizon View 5.3 was originally supposed to be Horizon View 5.2.1 and was changed to 5.3 last minute. Hence, all the latest available documentation is still on 5.2 because it wasn't supposed to change. That being said, we still feel in the dark when it comes to compatibility with our shiny new 5.3 View Environment.

There's a KB for that...  =)

Compatibility Matrix for Horizon View Components During an Upgrade to Horizon View 5.3:

Furthermore, the best solution for checking vSphere component compatibility is the VMware Product Interoperability Matrix. Definitely worth bookmarking!

Wednesday, February 26, 2014

Introducing the Horizon View Configuration Tool

Ever wished you could just deploy an OVA to setup your new View environment? Now you can! Thanks to Marilyn Basanta - a Solutions Management Engineer at VMware!

The Horizon View Configuration Tool automates Horizon View 5.3 installation and deployment. It removes the complexities and manual steps required for setting up a basic Horizon View deployment.


The vCT ships as a virtual appliance with all the required VMware components to set up your Horizon View environment. After providing a Windows Server 2008 R2 SP1 ISO, an ESX host (not managed by vCenter), a few parameters, and licenses, the tool will provision your environment dynamically and automatically. The vCT deploys the following components:

  • Virtual machine with Active Directory Domain Controller configured (or you may integrate with the existing DC in your environment)

  • Virtual machine with Horizon View Connection Server installed

  • Virtual machine with Horizon View Composer installed

  • vCenter Server Appliance virtual machine deployed and configured

** Note this is a Tech Preview and is NOT going to be supported by VMware Global Support Services. 



Follow by Email

Blog Archive