If one of our employees wants to work from outside we give them access through ScreenConnect to their PC in the company. With WOL they are able to turn the PC on at any time they want.
A better way would be if ScreenConnect could initiate a new RDP session on a given terminal server where the user can logon with his credentials so that there is no need to use of an extra PC.
I had a similar idea. Other members of my small team (6 I.T. staff total, supporting 350ish personnel) have a habit of using ScreenConnect to remote in to servers or other devices where there is no user to support, where an RDP session would be much more secure and also not consume a license. When I suggest that they stop this, the response tends to be that the list of machines within ScreenConnect is just much more convenient than manually typing in the computer name into MSTSC.
I'd like to see a join option (for Access sessions) which triggers an RDP session directly between the host and the guest. (If there is no direct network connectivity between the two, then perhaps fail over to a standard ScreenConnection session? Or just let the host know that it failed and they can do a SC connection manually.)
After 5 years and several "started" and "under review" tag changes I would like to hear, if anything is on the way!?!
Yes, there is one approach: the bridge extension. But it isn't really usable for our case. In this thread there are really good ideas for integrating RDP that would give much more opportunities for using connectwise control!
I wanted to add to this since the original request mentioned doing this without an additional PC.
The bridge would probably work great for server environments where a server/gateway/bridge hosting the agent could be running 24x7 but in desktop environments that might not work as well. Also companies that use Automate might not be able to use this feature. Our staff primarily uses Control in Automate via a plugin because we have all our permissions built in Automate.
Then when users are in Automate they could select RDP that would tunnel over the control session. Making more users happy with one change.
Great work - almost ;-)
I love to see this solution and after a quick look I have these suggestions:
1. You'll have to fill in and save user credentials to use/initiate an RDP connection. If you don't enter and save the logon credentials in the bridge entry a blank screenconnect window is opened and you don't have a chance to put in your credentials manually. E.g. we want to offer this to our staff to initiate an RDP connection over SC with their credentials. Do you have any idea to solve this?
2. It would be fine if the RDP resolution could fit automatically to the size of the SC window. Giving a start resolution is great but if you could change the resolution by maximizing the window and resize the resolution of the RDP session that would be a great improvement.
3. I don't know how you managed it technically. Looking at the options of mstsc.exe these options could be really very interesting to see in the RDP implementation of thebridge, too:
- /prompt - Prompts you for your credentials when you connect to the remote PC
- /multimon - Configures the Remote Desktop Services session monitor layout to be identical to the current client-side configuration.
- /span - Matches the remote desktop width and height with the local virtual desktop, spanning across multiple monitors, if necessary. To span across monitors, the monitors must be arranged to form a rectangle.
- /f - Starts Remote Desktop in full-screen mode.
- /admin - Connects you to the session for administering a remote PC.
Many times, we connect to server console sessions that are locked or in use. We would like the option to create a new session, by default, on specific servers or groups of servers, instead of connecting to the console.