Fantastic! Thank you Mike.

I just upgraded to 6.9 specifically to get access to this BackStage feature (and in anticipation of the 7.0 enhancement) but it is greyed out!

The link above says this is a requirement: "You must also have a license that includes the logon session switching feature." I have an on-premise / legacy license. Should I interpret the greyed out option to indicate my licensing is not good enough to qualify for this feature, or is this an oversight? I would hope this is not an attempt to coerce on-premise users to switch to the subscription model.

Kirsten, the Backstage feature with enhancement in 7.0 looks awesome! What is the approximate timeframe for 7.0?

This is great functionally but not logistically. There needs to be a way to map these presets to function keys, control key sequences, or some other way to make it quick to access the presets. Having to go to the More menu, select Preset Chat, Select the desire message, Click Insert, and click Send is too many steps to be meaningfully productive.

There is plenty of screen real-estate to put 20 soft buttons on the right side of the chat window, for example, labeled 1 to 20, so the user can simply click the desired preset. I realize this may be beyond what can be done within the confines of an extension, but it would be much more useful.

I think you are correct that my concerns are covered by these two other requests, although the wording is muddy in the first one so I'm not entirely sure. If it is saying that it should be possible to have a sub-administrator role that can perform some, but not all, administrative functions, then yes, that would do it, provided that one of the assignable capabilities is password reset.

Regarding the other request for a "forgot password" feature, in effect that allows for self-administration to a degree so would obviously be very useful in dealing with password resets.

Thank you.

Limited, but still useful. Thank you for doing this as an interim. Every enhancement is appreciated, even baby steps.

I will point out one additional requirement. The first bullet, "A user must have BOTH RunCommandOutsideOfSession AND TransferFilesInSession permissions to use the send files option" must be applied to AllSessionGroups, not merely to subgroups where the user role has access permissions.

Speaking for myself, I'd have no objection to Matthew's idea of being able to stretch or squeeze a window and have the aspect ratio follow it accordingly, e.g., perhaps by holding down the ctl key while resizing the window might have that effect. Such a feature would not be particularly useful to me personally, but I can understand situations where it would be handy as he indicates.

That said, there are many possible use cases where his solution doesn't really apply. For example, due to desk space limitations, my dual monitors are stacked rather than side by side. This limits how far I can go to enlarge a combined display image, so for my situation I need to split into two windows, and move one to the top monitor and one to the lower monitor.

It's also possible for the remote machine to have more than two displays, and in all sorts of configurations, so for example if the remote machine has two side by side displays plus a separate monitor on the wall configured in Windows as if it is stacked, the combined view will show an "L" shape with two displays side by side and a third stacked on top. Unless you happen to have a physical monitor situation that happens to be a good fit for this, no amount of monkeying with aspect ratios is likely to give a particularly usable result.

Given that there are uncountable possible variations on physical monitor configurations on both the remote and host side, the more general solution is to split the combined display into multiple windows, which can then be independently moved around and resized for best productivity based on the physical monitors available to the technician.

Yes, I'm a little confused by Matthew's comment as well. Right now, by default SC presents combined displays. The combo can be split into separate windows, but this requires a fairly cumbersome process. For example, two displays would be split into separate windows as follows:

- establish connection, viewing combined windows

- go to the display icon in the toolbar, move mouse over display 1, hold ctrl button, click on display 1; this opens a new window dedicated to display 1

- move the display 1 window out of the way, and go back to combined view

- go to the display icon in the toolbar, move mouse over display 2, hold ctrl button, click on display 2; this opens a new window dedicated to display 2

- you now have three windows open, which is apt to be confusing, so you probably want to move the display 2 window out of the way, go back to the combined view, and close it.

The point is, there is no good reason to require going through the above procedure, and having to do so introduces a distraction and delay in servicing the customer.

If I were on the SC design team, I would have a single toolbar icon for toggling between combined and separate window views. Such a solution would be extremely simple and elegant. Which view should be the default would then be essentially moot, as going from one to the other would be trivial and fast. Additional intelligence that would auto-locate separate windows on separate physical displays might be nice too, but not as essential as the core functionality of the mode toggle.

Further to Matthew's comment, having separate Windows does not constitute additional sessions and should have zero impact on resource usage.

I agree that splitting by default should be an option, however failing that (or in addition to that), you could put a split icon in the window toolbar so the split can be done quickly with a single click, rather than having to fish around in a menu and shift clicking multiple times.

Fully agree. This is one of my few annoyances with the product. The most common daily procedure (log in to a client) requires 5 steps (click menu, click ctl-alt-del, click menu, click send credentials, press Enter) when it could easily be one step (click Logon button in toolbar).

Granted, not every logon requires ctl-alt-del, but that could either be auto-detected or else split into two buttons, one with ctl-alt-del and the other without.

It's a shame this has been under review for two years. It can't be that difficult to implement.