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” 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.

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: