Package Base Details: vmware-horizon-client

Git Clone URL: (read-only, click to copy)
Submitter: eworm
Maintainer: eworm
Last Packager: eworm
Votes: 40
Popularity: 1.15
First Submitted: 2015-01-08 15:17
Last Updated: 2021-03-23 19:20

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 ... Next › Last »

jskier commented on 2019-02-08 17:06

@xerxies, yes, I'm also having that issue. CST turns into China whenever I use ArchLinux with the view client. Using Windows it works correctly. Will try the reg fix. This came up a few years ago (I think on the old client). I ended up running a logon script to fix it then.

xerxies commented on 2019-01-29 22:36

These are Non-persistent desktops. While I could change that in the base image, we do have users in multiple timezones that would use Time Zone syncing, and without creating a logon script or a GPO for my user account to change it, it's easier to just remember to change the Timezone every time I reconnect. I just was curious if anyone else has that issue, and if it is specific to the CST timezone. It does happen on my Arch laptop and my Surface which runs Antergos, but not to my co-workers Cent or Debian box in the same timezone.

eworm commented on 2019-01-29 21:13

I can not explain your issue in detail, but if disabling the timezone synchronization is an option import this to your horizon agent's registry:

[HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware VDM\Agent\Configuration] DisableTimeZoneSynchronization="true"

xerxies commented on 2019-01-29 19:34

This isn't an issue with the package at least that I'm aware of, but does anyone else have an issue with the timezone set on your Arch box not getting reported correctly to the Horizon Client?

Example: I'm in the US Central Standard timezone and the ViewClient_TZID variable is getting set to "CST" (which I would expect), but the ViewClient_Windows_Timezone is getting set to "China Standard Time". This could be an issue with how Arch is treating timezone abbreviations vs how horizon is.

CST Central Standard Time (North America) UTC−06 CST China Standard Time UTC+08 CST Cuba Standard Time UTC−05

eworm commented on 2019-01-03 09:58

The release notes list:

TLS 1.0 support discontinued Support of TLS 1.0 has been discontinued beginning with this release.

Possibly your servers do not yet support TLS 1.1 or 1.2?

viktormv commented on 2019-01-03 09:51

Do you also get an SSL error when using the latest version (4.10.0-1)?

2019-01-03T10:23:17.665+01:00> LVL:1 RC:-500 SCNET :scnet_client_open_ssl: SSL_connect: ssl_rv=-1, rv=1 (SSL_ERROR_SSL) 2019-01-03T10:23:17.665+01:00> LVL:1 RC:-500 SCNET :SSL Error Queue: err=336032002 (error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol)

The problem went away after I downgraded to version 4.9.0-1.

jvybihal commented on 2017-09-07 07:33

Possible conflicts with vmware-workstation package. Please see my comment:

eworm commented on 2017-07-09 19:53

Uh, I hate different files delivered by download servers. :-/
Just removed the documentation.

jskier commented on 2017-07-09 19:25

@eworm, the file seems to change based on the node downloading, that is the problem.

60e6770dbf6fcd57aaa81a26e86d9d1bd02a7ecbbc543e61cbc1e6d5a639bd9e horizon-client-linux-45-document.pdf

eworm commented on 2017-07-09 12:20

Does it help to remove the file from cache and try again?
What sha256 sum does the file have?