Douglas Lentz via plug on 20 May 2020 08:31:13 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
[PLUG] VMware Horizon Client Ubuntu16.04 works but not on 18.04 Why? WHY? |
Hi, all. I don't usually post to this group, so please excuse any etiquette lapses. My status is currently baffled. Perhaps someone with VMware client side experience can help?
My wife is employed by Jefferson. Due to the pandemic, she is working at home, using VMware. She is using my first Ubuntu box (call it "Liz"), but I would like to move her to my second box "Bernie" which is in a nice office. The VMware Horizon client is working on Liz, but not on Bernie.
Both boxes are identical Intel NUCs. Liz is running Ubuntu 16.04 Bernie running Ubuntu 18.04We are behind a Comcast router. Since Liz is working, it seems unlikely that port blocking is a issue.
There is no firewall on Bernie.I cannot connect on Bernie when I am the sole user in the household. Jefferson may be blocking simultaneous logins, but I can't tell.
On Bernie, the application gives no error message. It connects to other applications (Office 365, Human Resources) but "Remote Access Pool" (the one that gives access to EPIC EMR) fails without a message.
I have compared the vmware-horizon-client logs from both machines (more later). Googling the log contents (and trying to read VMware's documentation) has not helped, so that's why I'm posting here.
Connecting to the remote host begins with executing vmware-horizon-client. It then passes control to the default web browser .While I am waiting for authentication the process table on Bernie reveals that vmware-usbarbitrator and ftsprhvd are running. On Liz (the successful box) vmware-horizon-client and vmware-remotemks are running, in addition.
Comparing the log files from both machines: Liz is running Compiz and Bernie the GNOME shell, so there is some difference there, of course. And the request IDs, etc are different. Apart from that, the files appear identical until this point of deviation:
Liz (successful):2020-05-19 06:31:29.896-04:00: vmware-view 3894| TaskCombiner: CdkSetLocaleTask(DONE) removed, group task num:1, total task num:4. 2020-05-19 06:31:29.896-04:00: vmware-view 3894| TaskCombiner: SetResult for CdkSetLocaleTask(DONE). 2020-05-19 06:31:29.897-04:00: vmware-view 3894| Found CRL from http://crl.entrust.net/level1k.crl in cache. 2020-05-19 06:31:30.089-04:00: vmware-view 3894| Alt name 0 matches wildcard *.jefferson.edu 2020-05-19 06:31:30.089-04:00: vmware-view 3894| Found a valid EKU: TLS Web Server Authentication
Bernie (unsuccessful) 2020-05-19 11:27:45.941-04:00: vmware-view 16901| TaskCombiner: SetResult for CdkSetLocaleTask(DONE). 2020-05-19 11:27:45.957-04:00: vmware-view 16901| CdkUtil_SetLocalAddress: fd -1 < 0, not retrieving local address. 2020-05-19 11:27:45.957-04:00: vmware-view 16901| Disconnecting from broker https://connectvm.jefferson.edu:443/broker/xml 2020-05-19 11:27:45.957-04:00: vmware-view 16901| CdkUtil_SetLocalAddress: fd -1 < 0, not retrieving local address.
2020-05-19 11:27:46.023-04:00: vmware-view 16901| Not valid URL 'Add Server'On the original VMware installation I performed on Liz, I recall there was a problem with executable locations; the vmware-horizon-client would pass control to a web browser but the web browser, when done authenticating, couldn't find vmware-horizon-client. I may have fixed that with a symlink, but to be honest, it was two months ago and I don't remember clearly what I did, and I didn't anticipate doing it again. Anyway, I see nothing from the log files to suggest that executable location is the problem.
Is "local address" my public IP address? If anyone has insight into this, please share. Thanks to everyone! Does anyone have ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug