Horizon View 5.3.1 is out and supports vSAN!

Today, VMware announced the General Availability (GA) of VMware Virtual SAN 5.5 and Iā€™d like to take a moment to also introduce Horizon View 5.3.1. With this release, we are continuing the tradition of rapidly introducing innovations to market. And, now, the details:

  • Horizon View 5.3.1 supports VMware Virtual SAN 5.5. VMware Virtual SAN 5.5 is a component of VMware vSphere 5.5U1.
  • Horizon View 5.3.1 when used with VMware Virtual SAN 5.5 has been shown to reduce the total CAPEX cost of storage by up to 50%.
  • Horizon View 5.3.1 GA is intended for use with Virtual SAN 5.5 datastores only. There are no other new features in Horizon View 5.3.1 besides support for Virtual SAN 5.5.
  • Customers can purchase a Virtual SAN 5.5 license to deploy Horizon View 5.3.1.

How to distribute Mirage Client with logon script

One of the things that Horizon Mirage doesn’t give you out of the box is the ability to deliver the Mirage client to clients in a centralized manned, which is kinda awkward for a solution that tries to centralize everything.

I solved this problem with a logon script i use for client deployments; you can use and tweak my script as you want but don’t blame me if it doesn’t work for you šŸ™‚

Here’s the thing:

@echo off

rem echo Detecting OS processor type

if "%PROCESSOR_ARCHITECTURE%"=="AMD64" goto 64BIT

:32BIT
rem echo 32-bit OS
msiexec /norestart /quiet /l* "\\path_to_log\%COMPUTERNAME%-MirageClient.log" /i "\\path_to_setup\MirageClient.x86.15875.msi" serverip=<your_mirage_server> usessltransport=false
goto END

:64BIT
rem echo 64-bit OS
msiexec /norestart /quiet /l* "\\path_to_log\%COMPUTERNAME%-MirageClient.log"Ā /i "\\path_to_setup\MirageClient.x64.15875.msi" serverip=<your_mirage_server>Ā usessltransport=false
:END

Notice that the setup files have to be on a network share as well as the location of the log files where everyone have write access.

Using View Agent Direct-Connection

VMware released this piece of software that was previously available to VMware employees only or specific use case for customers that would make specific requests.

I’ve been deploying and supporting Horizon View environments since version 4.5 and if like me you can’t understand the use of VADC other than customer POC or lab use than you should watch this video which explains scenarios and use cases where it could be useful.

Upgrading VMware Mirage to 4.3

I’ve been waiting for a while for version 4.3 to come out for some interesting features some of my customers would be able to leverage, but I never thought I would be so surprised once I got to understand how to do it.

Essentially, there is no upgrade procedure, you just uninstall and reinstall the components just as they were before by using installer files from the 4.3 version.

Yes, I know, I thought the same but I can say that in the end it just seems to work. Even if there is no orchestration of a version upgrade that checks things around before proceeding I have to admit that the ease of operations is pretty nice.

Preparations steps are simple, just make sure you have the following written down:

  • Database server name
  • Credentials for the database server
  • Horizon MirageĀ server cache directory location
  • Cache size

Then just stop all Mirage services, snapshot all volumes, backup your DB and you’re done. A more detailed procedure can be found here but there is really not much more than that.

Now to the upgrade (or should I say reinstall?), the only thing to remember is that the order of operations must be respected:

  1. Select Control Panel > Add or Remove Programs to uninstall the system components.
  2. Uninstall all Horizon Mirage servers.
  3. Uninstall the Horizon Mirage Management console.
  4. Uninstall the Horizon Mirage Management server.
  5. Uninstall Horizon Mirage WebAccess.
  6. Use the new mis files to install the latest version of Horizon Mirage.
  7. Install the Horizon Mirage Management server.
  8. Install the Horizon Mirage Management console.
  9. Install the Horizon Mirage servers.
  10. Install Horizon Mirage WebAccess.

You will need to reboot the server after step 9.

A neat thing is that you won’t need to do anything to update your Mirage clients because once they contact the server they will self-upgrade with no downtime for the user. I just wish it would be possible to suppress the balloon notification that informs users about the upgrade or the possibility to decide when user clients will be upgraded.

I used this procedures twice on simple single server implementations and I had no issues.

Even if I would prefer a real upgrade procedure, in the end of the day i just want upgrades to work and this seems to be the case with Horizon Mirage, so no complains.

Horizon Mirage CVD Explorer AKA How to extract files from a CVD that is not actively being used

In Horizon Mirage the client has a nice little feature that allows users to self-restore files and folders taking them straight from their snapshots in the SIS (Single Instance Storage) database on the Horizon Mirage server that they are connected to.

Simple enough, but there is still a situation where you can’t use this feature. What if a specific CVD had been archived or what if simply the user or the sysadmin doesn’t have access to the endpoint where the Mirage client is installed?

In the Horizon Management Server there is some sort of a hidden feature (Mirage seems to have many…) that lets you open a CVD from the SIS, browse the filesystem and recover files and folders; the only limitation I’ve found compared to the full Mirage client experience is that you will not have the chance to choose from what snapshot to extract the files but you can only access the last one.

Fair enough.

Here’s what I did when I had to recover a folder from a user’s CVD:

1. RDP to the Management Server
2. cd “C:\Program Files\Wanova\Mirage Management Server”
3. run “Wanova.Server.Tools.exe CvdExplore”
4. Set output directory by clicking “Server -> Set output dir” (if you don’t set this value default location will be “C:\Program Files\Wanova\Mirage Management Server\CvdExplorer” for a default install)
5. Type in the path of the Mirage storage (eg. e:\mirage)
6. Type in the CVD number then hit enter (eg. 10001)
7. Browse the file system and find the file/folder you need
8. Right click and choose “Extract”
9. The application will automatically exit and you will find your files/folders in the output directory

Good to go!

Horizon Mirage 4.3 Released!

After quite a long radio silence i can tell you that since i’ve been working behind the scenes with Horizon Mirage, i am pretty excited about the announcement of the new 4.3 version!

This version provides the following new features and improvements:

  • The IT manager can now manage VMware View full clone desktops with Horizon Mirage. The IT manager can send image updates to View desktops, while keeping the user applications and data intact.
  • A new policy enables Horizon Mirage to work only with base and app layer updates, without uploads, reducing the overhead of the Horizon Mirage steady state on the end user’s machine.
  • Using Windows 7 migration with layers:
    • The IT manager can send app layers during the migration process.
    • Endpoints receive the base layer and the app layers in a single batch, and require only one reboot.
    • When the IT manager is following the progress of the migration, the app layers assignments under the Windows 7 migration task can also be followed.
  • The new web console supports the Protection Manager role, which has primary responsibility to ensure that the devices are protected and synchronized with the CVDs.
  • The dashboard for the Protection Manger role includes:
    • Last known upload errors, to help the IT manager focus on the main issues that are preventing users from uploading their data.
    • Centralization trends, to enable the IT manager to view the current state of the endpoint centralization process and determine how long this phase will take to finish.
    • Unprotected endpoints, to enable the IT manager to view, for a specific time period, which endpoints did not complete the upload.
    • Network disconnects, to enable the IT manager to view if there are slow remote branches that suffer from network disconnects that affect user uploads.

I’ll try to share my findings with this product soon as i did with Horizon Workspace.

Stay tuned!

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.

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

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&#8221; 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&#8221; 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.

%d bloggers like this: