TR Forums

We recently switched from an ancient VMWare View implementation that gave our shop floor access to a piece of software to a more modern Server 2016 powered RDP/remote app version (running the same acient software). We replaced all of our old thin clients with new ones (HP t420) and, generally speaking, things are working well - with one exception.

Here's what works:
1) The thin client automatically connects to the RDP server and logs in as the right user/launches the program, logs in as the right user to the program
2) If the thin client is rebooted it automatically reconnects to the existing session when it comes back up
3) If the remote app is closed, the thin clients automatically reconnects, starts the program, logs in, etc
4) Nightly, both the remote apps server and thin clients automatically reboot so everything has a fresh start in the morning

Here's what doesn't work:
If the program is minimized, I need to manually sign out the remote user for the terminal to be useful again. When the program minimizes, there is no indication on the desktop of the thin client of how to bring it back up (or at least what you'd expect to work, the pop-out task-bar, doesn't work). If you reboot the thin client, it reconnects to the minimized session, still in the minimized state. The server still sees the connection as active, so it never times/signs out. This issue is resolved by the overnight reboot, but I can't in good conscience tell people to wait for that. So, a few times a day, from the RDP server, I need to manually sign out a couple users because one of the ~100 people on the shop floor accidentally[?] minimized the program. This isn't a big deal, just takes a few seconds, but it's massively frustrating that it happens at all. Product documentation and Googling have failed me so far. Maybe I'm not using the right terms?

Any help from fellow gerbils would be greatly appreciated. Thanks!

I'll start by saying I have no idea how to fix your problem, but as I was reading it, I'm wondering if there is a way you can simply make the minimize button unavailable or otherwise not reachable through something like group policy? Or maybe make it fullscreen (like hitting F11 on a web browser) so those options aren't even there.

What about Alt+Tab? Does that show running programs on a thin client like a regular fat (?) client would?

Sorry I don't know an actual solution, but maybe a different approach will help until someone with more knowledge comes along

Fair questions. I was looking at some 3rd party programs and GP stuff that might help, but none of it was 100% right. There's a lot more stuff about stopping people from closing the program (which doesn't cause me problems) than stopping minimizing it.

The software itself has no form of full screen mode, sadly.

Alt+Tab is a thing on the thin client, but all it shows is the same no-help stuff as on the pop-out taskbar. It's like when the program minimizes on the server, it just disappears. I can click on the item in the taskbar that should restore it, but on the thin client I only get the screen of nothing that it apparently is showing me because the remote app is minimized. "Here look at this, I'm showing you what the app looks like on the server, nothing."

Does the application behave the same way if run on a local machine, or it does it restore correctly after a minimization?

If the latter, then it might be something with graphics settings in the RDP session.

It restores correctly when run locally.

This is more theoretical than a direct solution but does your thin client or server have settings for client-side vs. server side window decorations? Maybe that could help with producing some type of indicator that the window has minimized.

For a more direct approach that may not be applicable there's always this: https://www.techvigil.com/tips-tricks/4 ... l-windows/

I'm a little unclear on the problem as there might be some confusion on nomenclature.

Where exactly does the minimization issue occur, on the thin client side or on the RDP server? Remote app launches a "boarder less" RDP window of just the application without the normal RDP minimize/close/maximize button control. If you minimize the remote app, it goes to the thin client's taskbar and otherwise acts as if the application is running natively on the thin client.

If you are launching a full RDP session and then having it launch the application, that is not remote app.

Knowing if the minimization issue occurs on the RDP session or the thin client will help me better understand. I mean, it sounds like it's just disappearing on the thin client, but I want to make sure. Even if so, I'd like to know if it's really a remote app deployment or just a standard RDP shortcut as your thin client may have issues with remote app shortcuts specifically.

Convert wrote:

Remote app launches a "boarder less" RDP window of just the application without the normal RDP minimize/close/maximize button control. If you minimize the remote app, it goes to the thin client's taskbar and otherwise acts as if the application is running natively on the thin client.

That's what is happening. I just can't restore the window again afterward. The old way, with VMware View, we brought the whole desktop, but not anymore. I'm afraid I'm unclear about what you mean by the difference between a "real" remote app and a standard RDP shortcut. I can deploy the same app to Windows PC users via what I'd consider an "RDP shortcut" to the same server. However, on the thin client, I configure it with the server name/login info, and it shows the list of apps to choose from, then I tell it to automatically launch the right one. So, it's using the same mechanism/server as the shortcut PC users use, but the connection is 100% automated by the thin client (except for the problem I'm describing).

Based on chuckla's post, I found my way to a reg key for "RemoteDesktop_SuppressWhenMinimized" but that's client-side for Windows PCs. Not sure if the thin clients have an equivalent, or if that's what I need. Except for the thin clients, this is a Windows operation, so my "decoration" options (as I understand them) are limited - but that could point me back to GP changes I'm ignorant of. I don't know, and haven't found, how to serve up a maximized remote app with the min/max/x bar removed - which would be ideal.

I don't have a solution for you, though I can think of several hacky ways around it (which are probably already implemented in the 3rd party programs you've looked at -- ie disabling the minimize button/menu item).

What I suspect is going on: a Windows program has to handle the WM_SIZE messages that Windows sends whenever a user resizes a window (even if it's a fixed-sized window, there's at least one when the window is first created). Minimizing a window is just a special case of this, where Windows tells you the height and width of your widow is (0,0). (Early Windows coders inevitably tripped over this because their clever logic that adjusted the window contents on resize would produce a divide-by-zero unhandled exception when the window height or width was zero, aka "crash on minimize"). Back in the old (ie Win16/Win32) days, when memory was always in short supply and CPUs were slow, Windows would also take that opportunity to tell you to trim your working set, so programmers got in the habit of using minimize to "clear the decks" and go into a kind of background state. More recent (ie Vista and later) programs exist in a world where CPU resources are abundant and memory is plentiful, so they tend to ignore a resize of (0,0) altogether, with the result that while the window is still minimized, hovering over it in the taskbar produces a "live" thumbnail (because the window is still rendering is contents according to its pre-minimized dimensions, which Windows then BITBLTs into the thumbnail in scaled form) which is a desirable user experience.

You said this was an old program, so it probably is following the old minimize behavior to an extreme degree; VMWare, on the other hand, is expecting something more like the new behavior. VMWare should have some kind of compatibility bits to accommodate this, but I don't know enough about it to say for certain. Possibly VMWare looks at the compatibility options you can set in Windows (ie the ones in the "Compatibility" tab of the properties for the EXE) and one of those will change its behavior? I don't know -- like I said, I'm a VMWare newb.

Remote app shortcuts are special server-generated RDP shortcuts. They aren't something you can right click and edit like you can a standard RDP shortcut. While you can edit them in notepad, they are created by running the remote app wizard on the RDP server. I'm not sure if your thin client is able to generate true remote app shortcuts on the spot or not, but it's conceivable. That or it's doing something almost like a kiosk mode where your shell environment is the application, but then that's something else entirely.

I'm not personally all that familiar with thin clients, none of the clients I manage use them and the one's I have messed with were basic setups. I'm quite familiar with RDP servers and remote app deployments. I don't mean to split hairs about the remote app, I'm just hoping it will help us troubleshoot it better knowing exactly how it is set up. Remote app behaves differently than a manually configured RDP file and has different paths of troubleshooting.

I would suggest, as a test, to generate and deploy a true remote app rdp file from the server to your workstation and see how it acts. This may also fix the problem on the thin client (by deploying the rdp file directly to the thin client) as I'm really not sure what magic the thin client is doing to automate the application launching.