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.

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.

How to enable SSH root access in Horizon Workspace Virtual Machines

If you followed my previous posts you know how often and how useful is to SSH into a virtual appliance in Horizon Workspace and most of the time the commands you issue need to be run as ‘root’.

By default root access is not allowed via SSH and in order to get ‘root’ prompt you have to SSH as the user ‘sshuser’ with the same password as ‘root’ and then run:

su -



This can be annoying in particular using SCP to copy files because you are limited to ‘sshuser’ home directory and this force us to log back in as ‘root’ again to move the files we just copies.

In actuality there is a way to enable ‘root’ access straight from SSH to make things faster.

WARNING: I’M DESCRIBING THIS PROCEDURE FOR THE SAKE OF LEARNING BUT BY NO MEANS I SUGGEST TO DO THIS IN PRODUCTION BECAUSE IT WILL MOST LIKELY VIOLATE YOUR SECURITY POLICY.

  1. Connect to each VA console via vSphere Client or WebClient
  2. Select “Login” and enter as “root”
  3. vi /etc/ssh/sshd_config
  4. Find “PermitRootLogin”
  5. Change “PermitRootLogin” from “no” to “yes” and save the file
  6. service sshd restart

The “/etc/ssh/sshd_config” file should look like this:

#HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes	# default is no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

Now you can log in as ‘root’ directly from SSH.

Configuring redundancy for Horizon Workspace Virtual Machines aka How To Scale Horizon Workspace

Horizon Workspace can scale to many thousands of users, but obviously you are going to need more than just the mere default setup with 5 virtual machines if you want to get there.

As an example let’s take VMware own internal implementation for 13.000+ users so we can see how does Horizon Workspace scale:

  • 1x Configurator VA is used. 2vCPU, 2G Memory
  • 6x Connector VA is used. 2 vCPU, 4G Memory
  • 4x Gateway VA is used: 2 vCPU, 8G Memory
  • 2x Service VA is used: 2vCPU, 6G Memory (1 for HA)
  • 11x Data VA is used: 6 vCPU, 32G Memory
  • 2x Postgres Server is used: 4 vCPU, 4G Memory (1 for replication)
  • 3x MS Office Preview Server: 4vCPU, 4G Memory

VMware Architectural Diagram

As you can see most components can scale to many units, except the configurator-va. The configurator-va is a single point of administration when it comes to configuring your Horizon Workspace environment and it cannot be redundant.

Note: If you intend to increase the capacity of your Horizon Workspace virtual machines don’t forget to adjust the java heap size for improved performance.

In order to add a new virtual machine of any type, you must log in to the configurator-va virtual machine as root user and run the following command:

hznAdminTool addvm –type="VMType" --ip="new VM ip address"


This command can be executed only after the Horizon Workspace setup has been fully completed and you have tested that the solution is working.

The new virtual machines will have to follow the same requirements regarding IP addresses as the base virtual machines. For an overview of these requirements check “How to install Horizon Workspace using an external database”.

For Connector and Data virtual machines, this command creates the new virtual machine by cloning a base snapshot of the original virtual machine of the same type. The base snapshot is captured for all virtual machines during the initial deployment. The command fails if the base snapshot does not exist.

For service and gateway virtual machines, this command creates the new virtual machine by cloning the current virtual machine snapshot.

Let’s dig into details about having multiple instance of each type of virtual machine.

Note: The following commands, unless specified otherwise, must be executed on the configurator-va.

Multiple gateway-va
Companies can deploy multiple gateway-va in order to distribute load on more than one virtual machine thus providing both redundancy and scalability for this role. This is usually the first role that you want to make redundant since it’s the entry point for all users.

The specific command to add a gateway-va is as follows:

hznAdminTool addvm –type=GATEWAY --ip="new VM ip address"


Multiple service-va
You might want to add another service-va for the same reasons of the gateway-va.

Note: In order to add more service-va you must be using and external database.

The specific command to add a service-va is as follows:

hznAdminTool addvm –type=APPLICATION_MANAGER -- ip="new VM ip address"


Now connect to https://ConfiguratorHostname, open the System Information page and note how both the old and new service-va are listed and also how the new service-va is in maintenance mode. Before proceeding verify that the virtual machine was added correctly by checking the IP address.

We are going to need to open some firewall ports on all service-va, as referral for the coming configs use these:

iptables -A INPUT -i eth0 -s "OTHER_service_va_IP" -p tcp --dport
9300:9400 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -s "OTHER_service_va_IP" -p tcp --sport
9300:9400 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -s "OTHER_service_va_IP" -p udp --dport
54328 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -s "OTHER_service_va_IP" -p udp --sport
54328 -m state --state ESTABLISHED -j ACCEPT

Now we need to do the following to open firewall ports:

  • Run hznAdminTool listvms command to list service-va virtual machines.
  • Write down only the service-va virtual machine IP addresses.
  • Log in to the service-va virtual machine for IP address1 as root and go to the console.
  • Run the iptables command and use IP address2 as the value for the “OTHER_service_va_IP” parameter.
  • Log in to the service-va virtual machine for IP address2 as root and go to the console.
  • Run the iptables command and use IP address1 as the value for the “OTHER_service_va_IP” parameter value.

Next we need to run the following commands on all service-va:

service elasticsearch stop
hznAdminTool configureElasticSearch -ES_MULTICAST_ENABLED true service elasticsearch start
service elasticsearch status


And run the following commands only on the new service-va:

service rabbitmq-server stop
service elasticsearch stop
rm /var/run/rabbitmq/pid
rm /var/run/rabbitmq/lock
rm /var/run/elasticsearch/elasticsearch.pid
rm /var/lock/subsys/elasticsearch
rm -R /db/rabbitmq/data/*
rm -R /db/elasticsearch/*
service rabbitmq-server start
service rabbitmq-server status
rabbitmqctl stop_app
rabbitmqctl force_reset
rabbitmqctl start_app
hznAdminTool configureElasticSearch -ES_MULTICAST_ENABLED true service elasticsearch start
service elasticsearch status

Finally go to https://ConfiguratorHostname/cfg and click “Exit Maintenance Mode” on the newly added service-va. The Configurator updates all the gateway-va virtual machines and starts sending requests to the new
service-va virtual machine as well.

Multiple connector-va
Creating multiple connector-va will allow you to reduce traffic and reduce downtime. Other than that, creating multiple connector-va will enable you to use multiple means of authentication such as Active Directory user and password, RSA SecurID passcode or Kerberos-based Windows authentication. To enable multiple forms of authentication, you must set up multiple connector-va virtual machines.

Image

Depending on the type of authentication, you deploy a new connector-va in a different way. This subject will require a new post by itself but you can find details now in the Horizon Workspace Documentation Center.

Multiple data-va
User accounts are provisioned to a specific data-va virtual machine that handles their file activity. It is recommended that each data-va virtual machine serve no more than 1000 users, so you need to scale if you have more than that. When you add a new data-va virtual machine, the new data-va virtual machine automatically becomes available from the default COS host pool. The host pool for other classes of service that are created displays the new data-va virtual machine, but it is not enabled in that COS. To use a new data-va virtual machine in the other classes of service, the administrator must modify the COS and enable the data-va virtual machine.

The first data-va virtual machine in the Horizon Workspace configuration is the master node. This node contains the metadata for the data-va virtual machine user accounts. If you create additional data-va virtual machines, these data-va virtual machines are file stores only. When the master node is down, users cannot log in to their data accounts.

You can configure the host pool in the COS to use specific data-va virtual machines. In this way, you can manage where accounts are provisioned. For example, you add a second data-va virtual machine because disk space on the first data-va virtual machine is low. You do not want the first data-va virtual machine to be provisioned with any more new accounts once you have added the second node. From the Horizon Workspace Administrator Web interface, edit each COS to select the new data-va virtual machine in the Host Pool and deselect the other data-va virtual machine.

The specific command to add a data-va is as follows:

hznAdminTool addvm –type=DATA --ip="new VM ip address"


Note: Don’t forget to configure preview on each data-va.

Now the new data-va is in maintenance mode, to complete adding a new data-va do the following:

  • Restart each existing data-va
  • Log in to each data-va virtual machine as the root user to generate ssh keys
  • Reboot each data-va

The on each data-va:

su - zimbra
/opt/zimbra/.ssh/authorized_keys/zmupdateauthkeys
/etc/rc.d/memcached restart

Now go to https://ConfiguratorHostname and click “Exit Maintenance Mode”.

The new data-va virtual machine is ready to use.

Update: In Horizon Workspace 1.5 the base snapshot of the data-va is not used anymore to create other data-va. In order to create more data-va you have to create a “New datava-template Virtual Machine”.

Disclaimer: In this article i pasted parts of the official documentation.

Configuring data-va Preview

When using files in your Horizon Workspace Data section you can have a nice preview of the most common file types, like Microsoft Office, PDF, Text Files and such.

File previews can be generated in 2 ways:

  • Using LibreOffice Preview: File previews are generated on the data-va. This is a free option.
  • Using Microsoft Windows Preview: You can use this method to have a Microsoft Windows server act as a preview server. It requires Microsoft Office licenses.

Even if with the second option gives you the best compatibility, i go for the first option 99% of the times.

Enabling the LibreOffice Preview is a piece of cake: just ssh to the data-va, get a root prompt and then type:

cd /opt/zimbra/libexec
./libreoffice-installer.sh

This will download and install the software altogether. If you want to see progress of the process just do the following:

tail -f /tmp/libreoffice.download.txt

Once the process is complete do the following to apply the change:

su - zimbra
zmmailboxdctl restart

Now you should be able to use preview in Horizon Workspace.

Note: Password protected Microsoft Office documents cannot be previewed.

Adding NFS Storage to the Data Virtual Appliance

Note: If you are using Horizon Workspace 1.5 check the notes at the end of the post.

Before letting users add their files in Horizon Workspace it is important to dedicate enough storage space.

To add space to the data-va you have 2 options:

  • Add a larger VMDK
  • Add an NFS mount

Since it’s not advisable to go the VMDK way if you have more than 6TB of data, i always like to use NFS mount. Another reason is that files won’t be sitting in the data-va so whatever happens to that virtual machine we don’t have to worry about data.

In my lab environment i use Nexenta as primary mean of storage for all needs, including VMware datastore, so i just added another share to export via NFS to use with the data-va:

1

2

I added the data-va IP address as root access for the share and also added the Extra Option “anon=0”,

SSH to the data-va with the user ‘sshuser’:

su -
cd /opt/vmware-hdva-installer/bin
./mount-nfs-store.pl --nfs 192.168.110.15:/volumes/vsphere_01/data-va

Note: “192.168.110.9” is my data-va interface on the Nexenta network segment while “192.168.110.15” is my Nexenta interface and “/volumes/vsphere_01/data-va” is the folder path of my NFS export on Nexenta.

You should get an output like this:

NFS: 192.168.110.15:/volumes/vsphere_01/data-va
HOST: 192.168.110.15
192.168.110.15 is alive.
mount.nfs: timeout set for Wed Jul 31 11:47:39 2013
mount.nfs: trying text-based options 'hard,rsize=32768,wsize=32768,intr,addr=192.168.110.15'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.110.15 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.110.15 prog 100005 vers 3 prot UDP port 33327
192.168.110.15:/volumes/vsphere_01/data-va on /opt/zimbra/store29 type nfs (rw,sync,noatime,hard,rsize=32768,wsize=32768,intr)
Error occurred: directory does not exist or is not writable: /opt/zimbra/store29
zmvolume failed at ./mount-nfs-store.pl line 49.

You see an error? Well, it’s kind of normal. I don’t know why but this script always fails at the same point. After a while and with the help of VMTN Community i figured out where it fails and how to manually finish the job.

Let’s first check that at least the NFS is mounted:

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda3 39G 1.9G 35G 5% /
udev 2.0G 152K 2.0G 1% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/sda1 128M 21M 101M 17% /boot
/dev/mapper/zimbra_vg-zimbra 9.9G 1.1G 8.3G 12% /opt/zimbra
/dev/mapper/store_vg-store 9.9G 151M 9.2G 2% /opt/zimbra/store
/dev/mapper/db_vg-db 30G 1.2G 27G 5% /opt/zimbra/db
/dev/mapper/index_vg-index 9.9G 151M 9.2G 2% /opt/zimbra/index
/dev/mapper/redolog_vg-redolog 12G 159M 12G 2% /opt/zimbra/redolog
/dev/mapper/log_vg-log 9.9G 153M 9.2G 2% /opt/zimbra/log
/dev/mapper/backup_vg-backup 20G 174M 19G 1% /opt/zimbra/backup
/dev/mapper/data_vg-data 30G 173M 28G 1% /opt/zimbra/data
192.168.110.15:/volumes/vsphere_01/data-va 87G 32K 87G 1% /opt/zimbra/store29

Let’s change permission on the mount point so the zimbra user can write on the path:

chown -R zimbra:zimbra /opt/zimbra/store29
su - zimbra -c 'zmvolume -l'

The output would be something similar to this:

Volume id: 1
name: message1
type: primaryMessage
path: /opt/zimbra/store
compressed: false
current: false

Volume id: 2
name: index1
type: index
path: /opt/zimbra/index
compressed: false
current: true

Volume id: 3
 name: store78
 type: primaryMessage
 path: /opt/zimbra/store29
 compressed: false
 current: true

If you see “type: primaryMessage” and “current: true” for the mount point of the NFS mount then you are good to go, the new path is the primary storage for files.

You might find yourself with the NFS share mounted but with the missing entry in the output of the command ‘zmvolume -l’; in that case after changing the permissions we create the entry manually:

su - zimbra -c 'zmvolume -a -n store78 -t primaryMessage -p /opt/zimbra/store29 --compress false'
su - zimbra -c 'zmvolume -l | tail -7 | head -1 | cut -f2 -d:'
su - zimbra -c 'zmvolume -sc -id 3'
su - zimbra -c 'zmvolume -l'

The output now should look like the above one. Let me explain the above commands:

  • ‘zmvolume -a -n store78 -t primaryMessage -p /opt/zimbra/store29 –compress false’ : Creates an uncompressed store of type primaryMessage on the NFS mount point;
  • ‘zmvolume -l | tail -7 | head -1 | cut -f2 -d:’ : Finds the ID of the store we just created;
  • ‘zmvolume -sc -id 3’ : Sets the newly created storage as current using the store id (3 in my case);

Now files added by users to the data-va should be written on the NFS share.

Take a look at the CLI Command for Horizon Workspace Data Guide for more info on data-va commands.

8/7/13 UPDATE1: I fixed some IP addresses and paths in the outputs that don’t match my configuration. I have 2 labs and i seem to have taken a part of them in one lab and a part in another. Sorry for the inconvenience.

8/7/13 UPDATE2: It would seem like they fixed the script to mount the NFS share in Horizon Workspace version 1.5 since i used it to mount an NFS share in my lab today and i had no issue at all.

VMware Horizon Workspace 1.5 is out!

I went to check the documentation of Horizon Workspace and i can see there’s a whole new section for version 1.5!

Here’s the what’s new in the release notes:

  • Management of VMware® Ready™ Android Devices. Added Android container management for VMware Ready devices.
  • Oracle Support. Added Oracle and Oracle RAC as supported databases.
  • Unified Policies. Made changes to the policy framework for consistency and flexibility. Added a policy previewer.
  • Localized Support. Support for French, German, Japanese and Simplified Chinese localizations.
  • Change in VMware® ThinApp™ licensing tracking. Added per-device licensing support for ThinApp packages.
  • Customizable Getting Started Guide. A Word template with graphics that you can use to create a customized Horizon Workspace getting started guide to meet the unique needs of your end users. See the Getting Started ZIP file.
  • Numerous Bug Fixes. Improved the stability, performance, and scale of Horizon Workspace by implementing a variety of bug fixes.

The upgrade path from previous versions is described in the documentation so i guess once I’m done with the present series of articles i will write a post about upgrading.

How to replace Horizon Workspace 1.0 self-signed certificates with Microsoft CA certificates

UPDATE: If you are deploying Horizon Workspace 1.5 you should look at this post.

In the last post we generated new certificates from an internal Microsoft CA to use them as replacement of the Horizon Workspace self-signed certificates that are created during the setup process.

For certificates to work correctly, all parties in the process need to trust the Certification Authority; this include all servers and clients involved in the Horizon Workspace deployment.

Because of this, before applying the new certificates to Workspace virtual appliances we need to add our internal Microsoft CA to the list of trusted Certification Authorities; this step is not needed if you are buying certificates from a public CA that is already trusted, Verisign can be an example.

In this phase you will need to connect via ssh to all 5 virtual appliances with the user ‘sshuser’ (password is the same as ‘root’) and raise to ‘root’ with “su -“; you will then copy the CA certificate (ca.pem if you followed my previous post) via SCP in the home directory of user ‘sshuser’ then do the following:

cp /home/sshuser/ca.pem /etc/ssl/certs
c_rehash


Then do the following on the service-va and connector-va virtual machines:

/usr/java/jre1.6.0_37/bin/keytool -import -trustcacerts -file /etc/ssl/certs/horizon_private_root_ca.pem -alias horizon_private_root_ca -keystore /usr/java/jre-vmware/lib/security/cacerts


In my case:

/usr/java/jre1.6.0_37/bin/keytool -import -trustcacerts -file /etc/ssl/certs/ca.pem -alias vsphere-va -keystore /usr/java/jre-vmware/lib/security/cacerts


And run the following on the data-va:

/opt/zimbra/jdk1.7.0_05/jre/bin/keytool -import -trustcacerts -file /etc/ssl/certs/horizon_private_root_ca.pem -alias horizon_private_root_ca -keystore /opt/zimbra/jdk1.7.0_05/jre/lib/security/cacerts


In my case:

/opt/zimbra/jdk1.7.0_05/jre/bin/keytool -import -trustcacerts -file /etc/ssl/certs/ca.pem -alias vsphere-va -keystore /opt/zimbra/jdk1.7.0_05/jre/lib/security/cacerts


Note: The password to import the CA in the store is “changeit”.

Note: If you have an intermediate CA certificate you will have to run the same commands for that certificate too.

At this point your internal CA should be trusted but at times I’ve seen this happening only after a reboot of all virtual machines, so let’s just stop the vApp and restart it.

Changing the certificates is a less tedious process and it can be performed entirely using the web interface. Open your browser and connect to the Workspace admin page, in my case https://workspace.myvirtualife.net/admin and go to “Settings” -> “View Virtual Appliances System Configuration”:

1

Then click on “SSL Certificate” and paste certificate (horizon.pem) and private key (key.pem) from the files we created earlier, then press “Save”:

2

You will get a green box as a confirmation.
Now go to “Module Configuration” -> “Go To Connector”:

3

Now go to “SSL Certificate” and do the same as you did before pasting certificate and private key:

4

Now you should be able to connect back to the Workspace admin page and notice that you are running with the new certificates, and in my case i have no certificate warning because my workstation is domain joined and by default it trusts the Microsoft CA:

5

Well that’s great, isn’t it?

There’s still a lot of work to do to complete our environment but are well on our way.

More in the posts to come, see you there!

Using a Microsoft CA to generate certificates for Horizon Workspace

During installation of Horizon Workspace in the last post we used self-signed certificates for simplicity but when you will put Workspace in production you will definitely want to replace those certificates.

In this post we will use an internal Microsoft CA to request certificates for our Horizon Workspace implementation.

Note: The installation of a Microsoft CA is outside the scope of this article.

If you connect to your Horizon Workspace FQDN you will see the classic browser warning when you connect to an SSL website which certificate has been released by a Certificate Authority you don’t trust.

In fact if you take a close look at the certificate you will easily notice the following:

1

You can see how we don’t trust the CA as it is stated in red and as you can see from the certificate tree at the top.

We need to create a certificate request to pass to our Microsoft CA so that it can process it and spit out a certificate for us. There are several tools to create certificate requests but i like to use OpenSSL because it is available on almost every operating system so if you learn how to do it from that you will be able to do it in most situations.

The steps i am going to take will work on every platform, regardless the fact that i will do this on a Mac you will be able to take the same steps on a Windows box. You can find OpenSSL binaries for Windows here.

On a Mac, open a Terminal window, move to the “/bin” directory of your OpenSSL installation and run the following commands:

sudo openssl genrsa -out key.pem 2048
sudo openssl req -out horizon.csr -key key.pem -new


After running the second command we will be presented with a few questions to compile in order to create a certificate request:

Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Lazio
Locality Name (eg, city) []:Roma
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyVirtuaLife.Net
Organizational Unit Name (eg, section) []:IT Department
Common Name (e.g. server FQDN or YOUR name) []:workspace.myvirtualife.net
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


The first command will generate a private key (key.pem) that we will use for our request, the second command will actually create a request file signed it with the private key we just created.

The request file (horizon.csr) can be opened as a text file and it should look like this:

-----BEGIN CERTIFICATE REQUEST-----
MIICuzCCAaMCAQAwdjELMAkGA1UEBhMCSVQxFzAVBgNVBAgTDkVtaWxpYSBSb21h
Z25hMRYwFAYDVQQHEw1SZWdnaW8gRW1pbGlhMRUwEwYDVQQKEwxNeVZpcnR1YUxp
ZmUxEzARBgNVBAsTCk5ldHdvcmtpbmcxCjAIBgNVBAMUASowggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC6XP30PjkBqv7f1K9KKDm5gqdJLh8l9E8S28TQ
pEHzWcoIAnMezkFmGZUpIiQch53dABEAzJoNjQT5rGl8+Dfzghn6gK/0KreiqT7H
Yz+YQqiYofQ9u6yUOPo6I/ZsbagWUnTQ1E4n30IizY/UoVpt592dyy2+qay7xAZU
Yu0LG71dsG1TfclflgBh1PjRSGyrSaYTrm0ZlV2V5r74SZlLHtlGISxRG9Khsdmg
Fnkdybxr2CcM/lvwMN63rZXaYx9n9zr8/4qbOVNVo6o5PN9f+rllss1CKddr8Y03
n+IK9c1Y5H2BnK0RJBJELT2fRmulbVpV60Uo4u+bEFe/9oSXAgMBAAGgADANBgkq
hkiG9w0BAQUFAAOCAQEAQIw6kkW3VEY1gRUYqq/m2FxmpKlfJQzDxoe0DjSW7lJz
QcJlc25rPRi9ZsLe9/+1RcpAwJPMBii6ZyBIqtp2dwqpgSjn4bPa1nOE1YDnwlOe
NrX5wSe9JOnGL1FXhfyuALd+dVFRHhX/aAQU//klcfC8QHIVPtD78EffHVciENza
ckVl1L86CWAg2fWnZmvku9DYEbHNS1MhpJLgXBM3Yf7+kFt+PorO2AxF2SL82PBE
DVzdRT8nFeP9heaU0Jia0ByVKS873KoAuQFbm9cf++uNdCbZE02RRDTzYcREqD0Y
zNVsrfGVFJj8xRNJ1qgGu4wz5k9SnHnevMzq8DB9FQ==
-----END CERTIFICATE REQUEST-----

This will be correctly interpreted by the CA as a valid request but we won’t be able to read it. If you want to check if everything is ok you can do it like this:

openssl req -text -noout -in horizon.csr


You will see plenty of info and among that you will find those you inserted in the request:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=IT, ST=Lazio, L=Roma, O=MyVirtuaLife.Net, OU=IT Department, CN=workspace.myvirtualife.net

Note: The common name value is what your browser checks to be the same of the website you are trying to access, if different it will throw an error.

To pass the request to a Microsoft CA just access the web portal of your CA and click “Request a certificate” -> “advanced certificate request” and then paste your request as follows:

2

Select “Web Server” then click “Submit” and download the Base 64 encoded certificate:

3

You should get a file called “certnew.cer” that i normally rename in “horizon.pem”.

You should also get the CA certificate file, to download it go back to the homepage of your CA and click on “Download a CA certificate, certificate chain, or CRL”, the you should be here:

4

Select “Base 64” and then “Download CA certificate”.
Whenever you download a certificate from a Microsoft CA it will be called “certnew.cer” so you can see why it’s a best practice to rename them, i usually call this “ca.pem”.

At this point we should have the following:

  • key.pem (private key)
  • horizon.pem (the horizon workspace certificate)
  • ca.pem (the certification authority certificate)

Clarifying the certificate formats chaos
Every guide you will find out there that instructs you how to generate certificates will most of the time do a bad job explaining the various kind of formats, the difference between them and when to use one kind or another. Since i don’t want to take credit for something i didn’t do i want you to know that the following is taken from this webpage where you will also be able to convert different types of certificates if you need.

When you are dealing with certificates you will find different formats such as pem, der, p7b, and pfx. A Windows server for example exports and imports .pfx files while an Apache server uses individual PEM (.crt, .cer) files. The following is a definition of the various formats i mentioned.

PEM Format:
The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extensions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.

Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files.

DER Format:
The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms.

PKCS#7/P7B Format:
The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extension of .p7b or .p7c. P7B certificates contain “—–BEGIN PKCS7—–” and “—–END PKCS7—–” statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat.

PKCS#12/PFX Format:
The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

%d bloggers like this: