VMware Switch for Android and VMware Horizon Workspace 1.5

Ever since Horizon Workspace 1.5 was out i wanted to write about Switch for Android but i don’t have a VMware Ready Android phone so i couldn’t test this new feature.

Fortunately VMware itself did what i wanted to do and certainly the result is much better 🙂

If you are curious about this subject go check this blog post.

Advertisements

Balancing multiple Horizon Workspace gateway-va with HAProxy

When working with Horizon Workspace the first component you will scale to multiple instances is probably the gateway-va since this is the access point of all users, just to make sure it’s always available for connections.

In this case you need a load balancer to direct all users to all the gateway-va you have in your environment; i wrote about commercial and open source load balancers and also how to build one with HAProxy in this post.

I’m going to show you how i configure it with Horizon Workspace but remember that since I’ve learned about HAProxy only relatively recently by Luca Dell’Oca my configuration is just the way i do it and not necessarily the best so use the comments if you want to contribute.

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------

global
log 127.0.0.1 local2 info
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
option accept-invalid-http-request
retries 3
timeout http-request 60s
timeout queue 30m
timeout connect 1800s
timeout client 30m
timeout server 30m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
listen stats :9000
stats realm Haproxy\ Statistics
stats uri /stats

#---------------------------------------------------------------------
# Redirect to secured
#---------------------------------------------------------------------
frontend unsecured
bind :80
redirect scheme https if !{ ssl_fc }

#---------------------------------------------------------------------
# frontend secured
#---------------------------------------------------------------------
frontend front
bind :443 ssl crt /etc/haproxy/reverseproxy.pem
mode http

acl workspace hdr_beg(host) -i workspace.myvirtualife.net
use_backend workspace if workspace

#---------------------------------------------------------------------
# balancing between the various backends
#---------------------------------------------------------------------
backend workspace
mode http
server workspace1 192.168.110.10:443 weight 1 check port 443 inter 2000 rise 2 fall 5 ssl
server workspace2 192.168.110.11:443 weight 1 check port 443 inter 2000 rise 2 fall 5 ssl

Try to add a gateway-va and experiment with HAProxy to test HAProxy as load balancer. You can use this article if you want to know how to do it.

There are few more things worth of noting:

  • timeouts are really long here otherwise users will experience disconnects because this is the kind of web app you keep open quite a lot;
  • on port 9000 on the HAProxy host you will find statistics, for example “lb.yourcompany.yourdomain:9000/stats”, that will give numbers about state of connections and state of backends, problems, etc…
  • “log 127.0.0.1 local2 info” is necessary if you want logging enabled which is so important when troubleshooting problems; a lot on how to read logs in the HAProxy documentation

if you intend to put a SSL cert like in my configuration, know that it has to be a chain of cert and private key like this:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

To make logging work and write to a separate file instead of putting everything in “/var/log/messages”, edit your “/etc/rsyslog.conf” file and make sure these lines are present:

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# HAProxy
local2.* /var/log/haproxy.log

Architectural Planning of Horizon Workspace 1.5 for External Users

You can also call it “Learn Horizon Workspace architecture in 5 minutes”.

I found it to be a really cool and simple explaination of a complex architecture. Enjoy!

Preparing vPostgres 9.2 as external Database for Horizon Workspace 1.5

Today in my lab i tried to install the new version of Horizon Workspace from scratch to test if all previous steps about the external vPostgres database are still valid.

There are very few differences:

  • Supported version for Horizon Workspace 1.5 is vPostgres 9.2 instead of 9.1
  • Passwords for ‘root’ and ‘postgres’ users are not randomly generated anymore but you enter them during the OVA import process
  • After completing the importing process timezone is set to UTC; you can easily change it from the console of the virtual machine
  • When editing “postgresql.conf” you will find that the file is almost empty; all settings are in the “postgresql.conf.auto” file in the same directory which is not supposed to be changed. All the modifications that need to be applied simply need to be added as new lines in the “postgresql.conf” file.

Besides the above the procedure is identical and seems to work just fine.

How to deal with Horizon Workspace 1.5 FQDN and certificates

In the past I’ve written about how to install Horizon Workspace 1.0 and one of the tricky parts was about the decision of Workspace FQDN.

In version 1.0 you couldn’t change it afterwards so you had to do it right from the start, in version 1.5 you can change it but it’s still pretty tricky so you should still know in advance how it should look in the end. It’s not mandatory but it would help a lot.

In Horizon Workspace 1.5 during setup you won’t be asked for the FQDN but it will be automatically set as the name you’ve chosen for your gateway-va when you’ve created DNS entries for the VApp.

After deploying and configuring Horizon Workspace just as it used to be, you can go here and change the FQDN and/or certificates:

1

In this screen you are able to:

  • Configure an external load balancer
  • Install custom certificates
  • Change Horizon Workspace FQDN
  • Regenerate self-signed certificates

A lot of people reported errors when trying to change the FQDN, the most common is this:

Invalid IDP host/port

The reason for the above is that during the change of FQDN a check is performed on the SSL certificate for the new hostname to confirm that its common name matches the new FQDN. Here’s what i get in the configurator-va logs when i experience the issue:

ERROR [tomcat-http–29] com.vmware.horizon.configurator.vm.remote.impl.ConnectorRemoteImpl – Error when updating Connector “connector_va” with new IDP Url. Response from server: “Hostname is invalid or not reachable”. Could not connect to the URL. hostname in certificate didn’t match: “old_workspace_fqdn” != “new_workspace_fqdn”

This would mean that if we are just changing the FQDN but hosts remain the same we would have to replace certificates before actually making the change, a lot like during version 1.0 installation, but the same procedure doesn’t seem to help because even if the new certificate gets applied it still exposes the old one at least in one page that gets checked and this generates the error above.

At the end of the day we want to get the job done in the best way possible, so i can share the 2 ways i found to take over this task. The goal i am setting to myself as final result include the following:

  • Making sure self-signed certificates are replaced
  • Every virtual machine has numbered hostname naming convention based on role to help scaling (eg. gateway01, data01, etc.)
  • Horizon Workspace FQDN is set as i wish
  • Horizon Workspace FQDN is not the hostname of one of the virtual machine

So here’s my two cents on how to do that.

Method 1
In this method we create DNS records in our internal DNS so that the FQDN is pointing at a load balancer:

192.168.110.20			cofigurator-15.vsphere.lab
192.168.110.21			service-15.vsphere.lab
192.168.110.22			connector-15.vsphere.lab
192.168.110.23			data-15.vsphere.lab
192.168.110.24			gateway-15.vsphere.lab
172.16.110.2		        workspace-15.myvirtualife.net

My FQDN is “workspace-15.myvirtualife.net” since this is testing version 1.5.

My load balancer is configured to redirect all requests for “workspace-15.myvirtualife.net” to “192.168.110.24” and i’ve installed a certificate on it with the common name “workspace-15.myvirtualife.net” as it should be. To generate certificates i’ve used my internal Microsoft CA.

Complete deploy and configuration, accepting default for FQDN and certificates; the FQDN now is “gateway-15.vsphere.lab”.

Now log in to “https://gateway-15.vsphere.lab/admin” and reach the screen where you can change the FQDN and configure it as follows:

2

I pasted the certificate of my internal Microsoft CA since that is what i used to generate the cert for the load balancer.

Clicking save will change FQDN on all virtual machines plus adding my internal Microsoft CA as a trusted CA. This is a nice improvement since in version 1.0 it was a manual process where you had to SSH all VMs one by one… go read previous posts to see how much fun that was. Thank you VMware for this improvement.

In the end it should all look like this:

3

Now, given that your users can access your load balancer, just connect to “https://workspace-15.myvirtualife.net/admin” and you should be good to go.

If you need users to access from outside the network, like from the internet, just publish the load balancer and create a DNS record with the Workspace FQDN that points to the public IP used to publish the load balancer.

Method 2
In this method we create DNS records so that the FQDN is actually the name of our gateway-va:

192.168.110.25			cofigurator-15-2.vsphere.lab
192.168.110.26			service-15-2.vsphere.lab
192.168.110.27			connector-15-2.vsphere.lab
192.168.110.28			data-15-2.vsphere.lab
192.168.110.29		        workspace-15-2.myvirtualife.net

My FQDN is “workspace-15-2.myvirtualife.net” since this is method 2 for version 1.5.

You can proceed with the installation as you did for 1.0 version.

During configuration just accept all default when it comes to FQDN and certificates.

If you haven’t generated certificates for “workspace-15-2.myvirtualife.net” do it now.

Now reach the “FQDN & SSL” section in the configurator-va as we did for method 1 and set it like this:

5

The certificate you are pasting needs to be a chain of certificates including the CA certificate as well.

As the documentation states, the certificate chain has to look as follows:

-----BEGIN CERTIFICATE-----

SSL Cert - Workspace SSL cert

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

Intermediate/Issuing CA Cert

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

Root CA Cert

-----END CERTIFICATE-----

Clicking save will change FQDN on all virtual machines plus adding my internal Microsoft CA as a trusted CA. I already stated how annoying that was to do this manually so once more thank you VMware.

After a few minutes you should find yourself back at the “FQDN & SSL” screen. Don’t expect any successful confirmation because you won’t get any but if you get no error it’s all good. Close your browser and connect back to your Workspace FQDN and you should see no SSL warning no more.

Now since i don’t want my gateway-va hostname to be the same as the FQDN let’s open the console, login as root and fire up yast to change it:

Before

After

We also need to create a DNS record that points “gateway-15-2.vsphere.lab” to gateway-va IP address. Make sure the PTR for that IP points to the new record and not to the FQDN record.

Reboot the gateway-va and go back to the “FQDN & SSL”:

6

Since the gateway-va and the Horizon Workspace FQDN are not the same, the configurator-va assumes there will be a load balancer. You still have DNS pointing the Horizon Workspace FQDN to the gateway-va and your internal users should not have the warning for the self-signed certificate anymore. You can add a reverse proxy/load balancer if you want for outside access. This is a good way if you don’t want multiple gateway-va but you can still add more if you also add a load balancer and point the Workspace FQDN to that.

This should take you where you want to go. Comment section is open if you have doubts about the procedure i described I’ll try to answer fast enough and help if I can.

Disabling a Workspace module in VMware Horizon Workspace 1.x

After installing Horizon Workspace you have to activate modules with a green button in the homepage of administration.

If you activate one by mistake though you have no way to deactivate it.

In KB2056300 there is a procedure which explains how to deactivate modules:

 

If a browser interface to the PostgreSQL database is available:

  1. Open a browser and connect to the PostgreSQL database.
  2. Connect to https://DatabaseServer:8443.
  3. Log in using your credentials.
  4. Expand the databases (on the left side of the screen).
  5. Select saas.
  6. Click Enter SQL.
  7. Paste the appropriate script in the SQL Script. For a list of scripts, see below.
  8. Click Execute.

If browser access to the PostgreSQL database is not available:

Log into the Appliance or virtual machine where the PostgreSQL database is installed as root.

su postgres

cd /opt/vmware/vpostgres/current/bin

./psql saas

Type in the appropriate script line from the list below and end it with a ; (semicolon)

/q

Scripts

  • To disable the View module, run this query:

    update saas.”Module” set “enabled”=FALSE where “moduleName”=’View’

  • To disable Web Applications module, run this query:

    update saas.”Module” set “enabled”=FALSE where “moduleName”=’SaaS’

  • To disable the Mobile module, run this query:

    update saas.”Module” set “enabled”=FALSE where “moduleName”=’Mobile’

  • To disable ThinApp packages module, run the following query:

    update saas.”Module” set “enabled”=FALSE where “moduleName”=’ThinApp’

 

Accessing Horizon Workspace as non-AD administrator

It can be useful to know how to access administration when we can’t using standard Active Directory users.

Try following URL for non-AD admin access:

https://horizon.corp.local/SAAS/login/0
username: admin
password: password you set during deployment

Reasons why you want to do that vary but it can happen that your AD users lose their admin rights or maybe you messed up moving in your LDAP path your admin user outside the configured scope in Horizon Workspace.

I found this tip in the community, as usual. Enjoy.

%d bloggers like this: