For some time we’ve suffered a problem with our Windows 7 VDI systems that has prevented us from applying Windows Updates.
If we applied any of the rollups from March 2018 onward the VDI session would reboot itself under one special condition. If a user/client used the Cisco AnyConnect VPN software within the VDI Guest then almost exactly 2 minutes and 10 seconds after connecting, the VDI machine would throw a fatal error and reboot. Instantly terminating the users session.
Continue readingI decided to upgrade my VMware Horizon View client today. It still has the same kind of issues as detailed here: https://warlord0blog.wordpress.com/2016/10/21/vmware-horizon-client-for-linux/
This time around my problems were with libgstreamer components. Even though I ensured they were installed the libraries were a different version that required by the client.
Specifically required:
On my Debian Stretch install I had 1.0 versions.
So a quick fix by linking these made the scan issues go away.
$ cd /usr/lib/x86_64-linux-gnu $ sudo ln -s libgstapp-1.0.so.0 libgstapp-0.10.so.0 $ sudo ln -s libgstbase-1.0.so.0 libgstbase-0.10.so.0 $ sudo ln -s libgstreamer-1.0.so.0 libgstreamer-0.10.so.0
On my Linux VMWare Horizon client (v4.5.0 5650368) it doesn’t seem to matter what choice I make about NOT Connecting USB Devices at Startup it still continued to take over my Logitech USB Receiver.
I’d have to use the keyboard and navigate the menu so I could get control of my mouse back. Thankfully I don’t have a Logitech keyboard that uses the same receiver.
It was an easy fix, but I don’t know why it does it. The permissions to the ~/.vmware folder and files all seem OK. IT’s an easy fix of just editing the file view-preferences and amending the line or lines as follows.
$ vi ~/.vmware/view-preferences ... view.usbAutoConnectAtStartUp = "FALSE" view.usbAutoConnectOnInsert = "FALSE" ...
After downloading the PCoIP firmware update to deploy to our terminals I uploaded it to a test station using the “Admin Web Interface” (AWI) – the built in web GUI on the terminal, not from the central management console.
It seemed to go OK, but when it reset the PCoIP processor, effectively a reboot, it came up with a dialog showing the message:
Warning : Multilanguage font pack not found !
Defaulting to English only : Please update firmware to enable multilanguage support
I tried re-uploading the file and still received the same result.
In order to install the client on Debian 9 (stretch) I’ve had to get libpng12-0 installed from Jessie here:
https://packages.debian.org/en/jessie/amd64/libpng12-0/download
Then had to create symbolic link for libffi.so.5 to the newer version that’s installed.
$ sudo ln -s /usr/lib/x86_64-linux-gnu/libffi.so.5 /usr/lib/x86_64-linux-gnu/libffi.so.6
References: https://communities.vmware.com/thread/545364
After running an SSL scan on our external facing Horizon Security Server, using Qualys’ SSLTest and receiving an A- rating, I wanted to fix that by getting at least an A. But in order to do that I needed to understand what was required to get it to an A.
The problem I faced was that I was being marked down for not supporting Perfect Forward Secrecy (PFS).
The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-
Import the signed SSL server certificate into the Windows local computer certificate store on the Windows Server host.
In the Certificate snap-in, import the server certificate into the Certificates (Local Computer) > Personal > Certificates folder.
Select Mark this key as exportable.
Click Next and click Finish.
For View Connection Server or Security server, add the certificate Friendly name, ‘vdm’, to the new certificate that is replacing the previous certificate. You should only have one certificate with the friendly name vdm, so make sure it’s only the most current certificate.
Right-click the new certificate and click Properties
On the General tab, in the Friendly name field, type vdm.
Click Apply and click OK.
Create file c:\Program Files\VMware\VMware View\Server\sslgateway\conf\locked.properties with the content:
checkOrigin=false
References: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2144768
c:\> cd "c:\Program Files\VMware\VMware View Composer" c:\> sviconfig.exe -operation=replacecertificate -delete=false
Restart the View Composer service “VMware Horizon 7 Composer”
Referenes: http://vhorizon.co.uk/how-to-replace-a-vmware-horizon-view-composer-ssl-certificate/
Upgrading VMware Horizon is going to be a fun task for the weekend. It means upgrading 3 connection servers, a security server, the vcenter server and the composer server. This is all so we can disable SSLv3 on the ESXi hosts they all run on.
Migration was originally planned from 5.3 to 6.2, as this is the earliest version that resolves the SSLv3 problem. But if we’re going to have to upgrade, why not go all the way to v7?
As part of our patching process we applied security patches to one of the vSphere ESXi servers. All seemed to go well until we tried to compose systems onto it. We ended up with VDI clients being added to the server, but they’d never start up.
Clearly this was something to do with the patches that were applied.
Checking the log bundle we produced it was certainly an SSL related issue. Those damned certificates again! Well not quite.
Reading through the vmware-vdicomposer.log I picked up on a few of these messages:
Machine Name: VDICOMPOSER, Timestamp: 24/10/2016 15:01:52, App Domain Name: SviWebService.exe, Thread Identity: , Windows Identity: NT AUTHORITY\SYSTEM, OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1, reason: ServiceUnreachable access host: vdiesx01.domain.local access port: 902 disk datastore path: [vdiesx01_fio] VDITestNew_1/VDITestNew_11-internal.vmdk expected certificate thumbprint:
Very strange, a blank thumbprint. Checking the VDI database table dbo.VPX_HOSTS we compared the expected thumbprint to the actual thumbprint on the vSphere server and all looked good. But something couldn’t be right.
Stuff I'm Up To 