Monday, January 26, 2015

Workspace Portal Administrative Consoles

Workspace Portal has had a few facelifts over the years. Some remember the Horizon Workspace 1.x days of the multi-vm vApp where 5 different VMs were responsible for 5 different services. One difficulty resulting from this architecture was different VMs, with different URLs, that had different settings. This vApp then went down to 4 VMs with Workspace Portal 2.0, and now all necessary services are handled in a single-vm vApp with Workspace Portal 2.1, simplifying deployment and configuration.

The configuration, however, done through Workspace's administrative links can still be a bit daunting to the new administrator.

Workspace Portal has 3 primary locations used to customize and configure the appliance. These 3 locations, or "Quick Links" can be accessed from https://:8443



Set it and forget it.

The first link is the Appliance Configurator. I like to think of this link as the "Set it and forget it" link. When you configure the settings from this page, you won't need to access the page very often anymore - things like your FQDN and your database connection. Clicking on this link, you'll notice it prompts for your Admin password you initially setup upon first connecting to Workspace, which brings us to the Configurator Admin page

NOTE: you can also access this page directly by navigating to https://:8443/cfg/setup



The most important settings configured from this page are the Database, SSL Cert, and FQDN. The optional settings are for setting up a syslog server, changing admin/ssh account passwords, and generating support log bundles. If you're ever opening up a support request with VMware Support, be sure to include a log bundle collected from this location.

Connecting services to Workspace Portal.

Next we'll look at the Connector Services Admin link. Think of this as where we'll "connect" Workspace to other services in your environment, whether it's your existing Active Directory users and groups, Horizon View desktops and hosted apps, SaaS applications, and the authentication methods for said services.

NOTE: you can also access thsi page directly by navigating to https://:8443/hc/admin/about



Finally you have the Workspace Admin Portal. Think of this as where you refine the end-results of your working instance. From here, you can access a tab called Settings which has some misceallaneous settings - things from obtaining SAML Metadata for your SaaS service providers, to tweaking your Authentication Methods for your synced internal and external users.



Related Documentation:
Introduction to Workspace for Administrators
Share:

Wednesday, January 7, 2015

Running the VMware Horizon View Client 3.2 in Ubuntu (and Ubuntu derivatives)

Have you ever felt like a Linux user in a Windows VDI world? You're not alone!

Any Linux fans that are familiar with the world of VDI know that the VMware View Client for Linux has appeared stuck at version 2.2 for what seems like forever. Then in December of 2014, we were given a lovely gift: the Horizon Client for Linux version 3.2.

In your excitement you download the client, open up your terminal, run the installer and launch the new release only to find your system has missing requirements. In the Users Guide for the 3.2 client, you'll find a laundry list of system requirements and pre-requisites. The trickiest of all being the OpenSSL requirements (not to mention 64-bit systems aren't supported).

This post will walk you through getting past the system requirements and getting the 3.2 Client up and running on your Ubuntu (or similar) system.

In this article, I will be installing the client on Linux Mint 17.1 x64, but please be aware that VMware will not support the Horizon View Client outside of the system requirements outlined in the Users Guide.


  1. Download the .bundle from VMware here

  2. Run the installer by typing  sudo sh ./file_name


  3. This should launch the GUI installer. Accept the EULA


  4. Configure your desired settings and verify the installation was successful



Hooray! You should be done right? Well most likely you may run into issues once you click that Scan button. You'll find that you pretty much bombed your mid-term:



Not to worry though, this is very simple to fix!

Now for my purposes, the only lib files I care about are libcrypto.so and libssl.so. I won't be using USB redirection or RTAV. What we need to do is create symbolic links between the 1.0.0 versions that I have installed, with the 1.0.1 naming that the Horizon Client wants to use. Let's start by finding where our current files live

  1. Use the find command to locate your libcrypto and libssl files

    sudo find / -iname libssl*

  2. Once you have the full paths of the files, create your symbolic links using

    sudo ln -s source_file destination_file


  3. Now re-run your Scan test - you should find the appropriate files are now back on track to walk at graduation!



And congratulations are in order! You should now have a functioning 3.2 Horizon Client. You may see a dialog that reads:


VMware Horizon Client requires openssl-1.0.1i or above. But 1.0.1f seems to be installed on your system. This discrepancy could result in unexpected problems or even security leaks. Contact your administrator for more information.

Since you're using your system's openssl lib files, any system updates that affect these files shouldn't break compatibility - however if openssl gets updated later on, you'll likely need to update your symlinks to reflect the updated lib versions.




Now go get some work done!

Share:

Follow by Email