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

Read More

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!

Read More

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 www.vmware.com.. 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/client-download.properties


2. You should see a single line that reads winSyncClientUrl=http://www.vmware.com
   
   


3. Simply change the value of winSyncClientUrl to the desired URL. You could set this to the actual VMware Download page for Workspace Products (https://my.vmware.com/web/vmware/details?downloadGroup=HZNP210&productId=419&rPId=6533) 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!

Read More

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 https://workspacehostname.com/horizon_workspace_rootca.pem.

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

environment

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,

dataEncipherment

extendedKeyUsage = serverAuth, clientAuth

subjectAltName = DNS: ext-con.company.com, DNS:

view.company.com, DNS: gtw.company.com, DNS:

services.company.com 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

:wq

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., portal.acme.com)Make 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:

-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate)
-----END 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.

[Important]
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

Troubleshooting changing the Workspace Portal FQDN
Apply Public Certificate Authority to vIDM

Using SSL Certificates in Workspace

Apply Workspace Root Cert to the Load Balancer

Read More

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 (http://kb.vmware.com/kb/1008046) by opening a command prompt on the Connection Server and type: vdmexport > vdmconfig.ldf


2. Connect to ADAM via ADSI Edit (kb.vmware.com/kb/2012377)


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.

Read More

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/nginx.pid;

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

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM- SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK';

 

    # 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)

How to setup a CA

The Most Common OpenSSL commands

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!

Read More

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..

CPU	AMD A10 6800k	$129.99	http://www.newegg.com/Product/Product.aspx?Item=N82E16819113331
Memory	G.Skill Ripjaw X 8GB	$84.99	http://www.newegg.com/Product/Product.aspx?Item=N82E16820231654
Mobo	MSI A78m-E35	$59.99	http://www.newegg.com/Product/Product.aspx?Item=N82E16813130741
Hard Drive	Seagate Hybrid Drive ST1000DX001 1TB	$96	http://www.newegg.com/Product/Product.aspx?item=N82E16822178381
Case	Antech Mini P180	0	http://www.newegg.com/Product/Product.aspx?Item=N82E16811129041
PSU	Thermaltake TR2 TR-600	$24.99 (with rebate)	http://www.newegg.com/Product/Product.aspx?Item=17-153-166

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 <<

Read More