Monthly Archives: August 2014

Implementing signed certificates to Horizon View servers

In this post i will describe how to implement signed certificates to Horizon view servers using opensll.

Most of Vmware products use the installer signed certificates (which is good for testing) but they usually recommend to replace them with CA signed to make the infrastructure more secure.

I found the available documentation little thin, so i thought i will describe it.

So what you will need, opensll. Openssl is a command line tool that creates / signs / converts / does anything that relates to certificates and is open.

Access to a CA server to sign the certificate, in this case i am using Microsoft CA server but any other will can be used (although with a little change in the process).

The first step is to create an openssl config file. I prefer using config files because they help avoid the interactive wizard and by that avoid mistakes.

This is an example of a config file:

[ req ]
default_bits = 2048
default_keyfile = vdi01.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS: vdi01, IP:,

[ req_distinguished_name ]
countryName = US
stateOrProvinceName = NC
localityName = Durham
0.organizationName = RonenINC
organizationalUnitName = Engineering
commonName =

Change the Italic parts of the file to your use case. Save the file as the name of the server – vdi01.cfg .

Important: The “commonName” field should be the fqdn of the server (if the server will be behind a load balancer , it should be the fqdn of the load balancer.

The “subjectAltName” should be the the short name of the server, its IP address , or any other url that you might use to connect to it. SAN are very usefull when you connect to a server with different names / URL’s.

Next step is to create the certificate signing request and the key file. It is done with one command using the launching Command with Administrator privileges:

openssl req -new -nodes -out vdi01.csr -keyout vdi01.key -config vdi01.cfg

This command will read the config file we created, take the info in it and create 2 files: the private key, and a certificate signing request file.

In this step we will use the Microsoft CA server to sign the csr request. You can use any other CA server (this is what i have) But the process will be a little different.

Use IE to launch the url of the ca server :

Click “Request a Certificate”

Click “Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file”

Open the csr file we created and copy all its content (including header).

Paste the csr content into the CA server and select the certificate template you need (this depends on your environment).

And click “Submit”

If everything is ok, you will be prompted to accept and choose the encoding of the certificate , choose “Base 64 encoded” and “Download certificate”.

Save the certificate to the same location as your key file is.

Change the certificate file type from cer to crt (It has no affect on it) , also rename it to the name of the server (to make it clearer) : “vdi01.crt”.

Since Horizon view uses the pfx files and not just the certificate we will have to create it and import into it both the certificate and the key file:

openssl pkcs12 -export -in vdi01.crt -inkey vdi01.key -name vdm -passout pass:testpassword -out vdi01.pfx

Important: Dont change the name or the password, This is the way the server expects it to be.

Last step is to install the new certificate on the Horizon connection servers, copy the pfx file to it.

Launch the mmc from the Horizon view server, add the “certificate” snap-in and select “computer accoubnt”.

Right click the “personnel” folder and “Import”.

Select the pfx file we created, check mark “Mark the key as exportable” and “include all extended properties”.

Rename the old “vdm” certificate to another name (“vdm-old”) – the horizon view server looks for “vdm”.

Make sure the new certificate we imported is named “vdm”.

Restart the Horizon view services and make sure you can connect to the admin page and also with the client without getting certificate error on the browser or client (the services may take couple of minutes to start).

Couple of things to pay attention to:

You will have to go to the view configuration – connection server edit page, and edit the ip’s and url to match the certificate and what the users will use. generally, for internal users the default will work fine. I also found out that i can load balance the blast and https secure tunnel , although not supported by vmware and can cause all kind of issues.

PCoIP cant be load balanced.

Verify in the admin page dashboard that you dont have error message on the connection server. Usually if the certificate url does not match what is configured as url for the connection server there will be an error.

When using external security servers in the dmz (where else would you put them) make sure to create certificate with the public URL’s and IP’s. And also to configure it in the security server configuration. Again to avoid the certificate errors.

Thats it, this is how to install signed certificates to Horizon view servers.


Using the OVFTOOL

OVFTOOL is a command line tool that lets you import / export vm from any product / format to any (almost). It supports vsphere, vCD, vmware workstation, vmware fusion, ovf, ova and some more. It can also convert formats.

It is also very useful and easy to move vm’s across vCenter servers without the need to do it in 2 phases and having some kind of storage in between (this is my most useful scenario).

The syntax is simple, just add the source and destination of the vm, and if needed some options.

For example, to export a vm from vsphere to ovf format:

ovftool vi://vcenter/datacenter/vm/vmname c:\ovfs\vmname.ovf 

One thing to remember, ovftool is case sensitive, so when typing the locators they have to much to what is configured in vsphere. It can be tricky when having complex inventory tree.

When deploying into vsphere we need to configure the datastore where the vm will reside and disk mode and also the network it will be connected to (if it has 1 nic). Here is an example of copying a vm from vcenter to vcenter:

ovftool -dm=thin -ds=vol1 -nw=net1 vi://vcenter1/datacenter1/vm/vmname vi://vcenter2/datacenter2/host/cluster/ 

-dm – the disk mode , can be thin, thick, etc..

-ds – the datastore target for the vm.

-nw – the network the vm will be connected to.

The ovftool will prompt for credentials to login to the vcenters (can be injected in the command line for scripting) so the user that uses that must have access to the resources used.

Another interesting option is the –net , when the vm has 2 nics, the ovftool needs to know which nic goes to which network so we have to assign them both:

ovftool -dm=thick -ds=vol1 –net:sourcenet1=targetnet1 –net:sourcenet2=targetnet2  vi://vcenter1/datacenter1/vm/vmname

Where, “sourcenet1” is the original network, and “targetnet1” is the network that nic will be connected to in the target location.

There are alot more options like powering on the vm after deploying, changing the memory size, cpu count etc…

The user guide and bits are here.


vSphere Inventory Service

So, since version 5.1 the inventory service became a separate / stand alone component of the vSphere suite. You can install it on the vCenter itself or on a dedicated server.

My first thought of it was that it is used as in memory caching service for the web client, so it can serve read request and decrease load on the vCenter service, and if that’s the case no need to back it up. 

But recently i found out that it does store data that is not stored anywhere else, and that is tagging and storage profiles. If you are not using any of these you really dont need to back it up, but if you do, or if you use vCloud director (which uses storage profiles) it is very important to back it up.

This KB describes how to backup and restore the inventory service.

Another thing i found out lately, is that the inventory service uses a xml db (x-hive) and sometimes it can become corrupted (search will error / timeout). In that case you should restore the db or reset it.

If you dont need the data in it , because you dont use tagging or storage profiles, you can just reset it, the process is described in this kb , and quite easy to implement.




Virtualizing MSCS 2012R2 on vSphere

I was working lately to Virtualize MSCS 2012R2 clusters on vSphere.

According to this kb, it is officially supported on vSphere 5.5 update 1.

I have been spending some time on it and, but for some reason the cluster validation kept failing because of “disk arbitration” test problems.

After contacting all vendors (VMware, HDS, Microsoft) i found out, there is a bug that is related to active-active arrays (in my case VSP) that causes the validation to fail.

If you use any kind of ALUA array, you are bug free, and should be able to implement this.

This bug is handled at the moment by vmware engineering and a fix should be released soon.

UPDATE: this kb popped up , that explains the situation. No solution yet.

Tagged , ,