Now I've tried the most anticipated feature (least for HiEd) of Horizon 8: Linux applications.
However there seems to be few issues with it:
- If a user launches several applications they all appear in a same window in a stack. Most recently started on the top.
- If a user minimizes an application, it's lost from the client view.
- If an application has a indication bar gadget (like the Remmina), the application gives an error about it.
- It takes quite a time to start the applications, also the subsequent ones, even they are all eventually started from the same underlying session, which means that there is only a single login.
- Horizon Client application window doesn't show the name of an open application in the title bar.
- From Horizon HTML5 Client (launched with a Chrome), the Linux applications doesn't appear at all. Only gray screen is shown.
Horizon Client 2006 for Mac OS
VM: Ubuntu 18.04 LTS ( 2006 agent installed with --multi-session parameter), Mate Desktop environment, Instant clone farm, SSSD authentication provider, Microsoft Active Directory bound computer accounts
I think that VMware cannot never beat Microsoft in their own field (I mean WVD), but WVD doesn't have one thing at all: Linux Applications, which is super cool for Universities, where Linux has a strong base on the field of natural sciences.
Thanks for the tip. I changed SSODesktopType to UseGnomeClassic in /etc/vmware/viewagent-custom.conf and applications work better now. Still we need Mate, as it is the desktop environment number one in our environment, so I just need to use different host farms for applications (configured for Gnome Classic) and published desktops (configured for Mate). Maybe there could be a separate setting for applications?
Still some issues persists with Gnome Classic
- Still no luck with a HTML5-client
- Applications started from shell scripts like /bin/sh "/usr/share/tmcbeans/bin/tmcbeans" won't start at all.
- Chrome icon of a launched application is not the correct one, least on a MacOS client.
- Scrolling in some applications is bit cumbersome (mainly Remmina).
- If user has Teams client autostart on, it starts instead of the selected application. User story: chose Chrome, got Teams.
Deleting ~/.config/autostart/teams.desktop remediated this issue.
Nevertheless, this is a huge improvement, I think I take this to production even these limitations still exists.
Just a short update,
By reconnection (with gnome classic) the open applications stacked again into a single windowed view, and when in such state minimising an application makes it to vanish completely.
I'm happy to show if any VMware rep is interested.
Thanks Perttu for you feedback.
'SSODesktopType' option is for Single Sign On, it doesn't affect the remote application behavior. For now we don't support web/mobile client. When launching app from scripts, did you run the script from background remotely(e.g. via putty/ssh), or in another opened remote application(e.g. gnome-terminal)? For the former, please make sure you have the right environment variables(e.g. DISPLAY/XAUTH).
For the Chrome icon, Remmina and Teams auto issue, can you provide the reproduce steps/instructions and upload the snapshot if possible so that we could do more investigation? Your feedback will help us improve the user experience.
> 'SSODesktopType' option is for Single Sign On, it doesn't affect the remote application behavior.
It did affect however . There is a normal login behind the remote application, and this chooses the desktop environment for user.
For other questions, should I share the screen captures and reports here publicly or privately?
I was also able to fix the application entry launched from a script. The issue originated from this view, where I chose to create a new application entry from Netbeans with TMC.
However, aplication execution parameters were not copied into the application entry. Start menu item is exactly:
root@-:~# cat /usr/share/applications/tmcbeans.desktop
Name=Netbeans with CS TMC 1.4.0
Comment=Netbeans with Dept. of Computer Science Test My Code 1.4.0
So adding the omitted argument "/usr/share/tmcbeans/bin/tmcbeans" as a parameter into the application entry resolved this issue. Hence, the findings are that VMware application pool autogenerator should take the execution arguments also into account when creating application pools.
Regarding other issues I've now shared screen caps with VMware.