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.

Advertisements

How to upgrade Horizon Workspace 1.0 to 1.5

Since a new version of Horizon Workspace came out I’ve been curious about differences and improvements, so i upgraded it to version 1.5.

I have to say that, besides some differences here and there in the look and feel and the new functionality to manage VMware Ready Android devices, I have already found a nice improvement in the way you mount the NFS store in the data-va because finally the procedure simply works and there’s no need of crazy workarounds. I also suspect that they improved a lot the way you change self-signed certificates compared to what it used to be; more on this when i will have tested it.

Note: You can only upgrade if you have completed the setup procedure and you have a fully functional environment.

All commands need to be run from the configurator-va, just as usual, so let’s SSH into it, then:

su -
/usr/local/horizon/lib/menu/updatemgr.hzn check

You should get this output:

Image

As you can see it won’t recognize my vPostgres and this is normal. Since I’ve started this series of posts about Horizon Workspace installing the external database on vPostgres i also added the VM to the VApp to make sure it starts for first and stop for last. The first time i tried to upgrade i decided to ignore this error and went ahead with the upgrade which failed and left my Horizon Workspace installation in an unusable state so i reverted the snapshots, removed the vPostgres from the VApp and rerun the command and i could see no issue at that point.

Before going on and since it’s been so useful for me, i will show you how to snapshot all your VMs in the VApp at once so you can revert if you need. Since you might have more than just 5 VMs i like to use PowerCLI to take over this kind of task simply because it’s faster than working around the GUI:

Get-VApp Horizon-Workspace | Get-VM | New-Snapshot -Name "UpgradeHorizon" -Description "Horizon Workspace upgrade from version 1.0 to 1.5" -Memory -Quiesce -Confirm:$false -RunAsync

Given that you didn’t change the default name of the VApp (Horizon-Workspace) this will snapshot all the VMs included in it.

In the vSphere client you should see this:

Image

Once they are all completed we can go back to the configurator-va and start the upgrade with peace of mind:

/usr/local/horizon/lib/menu/updatemgr.hzn update

Now you should see a whole lot of downloading and installing. In my lab it took about 40 minutes for the whole procedure.

When the upgrade is done you have to shutdown and restart the VApp; since i still have the PowerCLI open i used it:

Stop-VApp -VApp Horizon-Workspace -Confirm:$false
Start-VApp -VApp Horizon-Workspace -Confirm:$false

You shouldn’t start it again until it’s stopped, so in order to see the status of the command i’ve omitted “RunAsync”.

Now check that your Horizon Workspace environment still works then you can check again for updates to see the current status:

Image

That looks al good, now you just have to remember to update your preview binaries in the data-va if you used the LibreOffice preview because there’s a new version, just do as usual.

If you’re happy with the result you can remove the snapshots we created earlier:

Get-VApp Horizon-Workspace | Get-VM | Get-SnapShot | Where { $_.Name.Contains("ToolsUpgrade") } | Remove-Snapshot -RemoveChildren -Confirm:$false -RunAsync

In my case i also had to put back the vPostgres VM in the VApp.

That’s pretty much it.

DISCLAIMER: PowerCLI is a powerful tool and should not be used to throw in some commands without understanding the effects. Before running PowerCLI commands in your production environment always test them and adjust them for your situation. I take no responsibility if you don’t test things out yourself first and your Horizon Workspace gets broken.

UPDATE: In the release notes it is clearly stated that in the documentation there are missing steps in case you have multiple service-va VMs. Please refer to the Horizon Workspace 1.5 release notes for the additional steps.

%d bloggers like this: