problem closing 'external' connection/session on jump host

ssh without external tool (e.g. putty) works!

Hello,

Thank you for contacting us regarding this,

I'd like to confirm the following:

• Which version of RDM are you using?
• Which type of data source are you using?

Let me know,

Best regards,

Hi,

2022.1.7.0 and 2022.1.23.0 (other users versions in between), 64-bit.
datasource: MS SQL Server

Best regards,
Clemens

Hello,

Thank you for your reply,

From my understanding, this is the expected behavior since RDM does not have a method to confirm if the "External" session has been closed.

Let me know if this helps,

Best regards,

Hi Samuel,
I have just got the task from my boss to ask if there is no workaround to close, restart, reset or any other method to use the external session again without to close the session on the jump host? The reason: if you have any other session running on the jump host, these have to be closed too ...
Would be important ;)
Thanks!
Best regards,
Clemens

Hello Clemens,

Thank you for your reply,

My apologies for the delay, from my understanding when launching a session in "External" mode RDM is simply using command lines to start the session.

Since that's the case, as mentioned RDM would have no method to confirm the session status. I'm afraid that to my knowledge the same would apply to Closing/Restarting the session, it would have to be done manually outside RDM.

Let me know if you have further questions,

Best regards,

Hi Samuel,
no problem! ;)

I understand that the local installed RDM might not get the session status from den RDM agent on the jump host. But it would be important that you can force a close/restart etc. of the session in the local RDM anyway, without to close the session to the jump host (which can include several other sessions itself!), despite the 'local' status.
Do you know what I mean?
Thank you!
Best regards,
Clemens

Hello,

Thank you for your reply,

I would like to confirm, are all these entries being launched in "External" display mode on the Jump Host? Are you also encountering this issue with "Embedded" sessions?

Let me know,

Best regards,

Hi!
Yes, "embedded" seems to work. The problem remains for external tools (e.g. NetSupport Manager, ...), ssh sessions etc. There should be an option to re-enable the connection entry (with the close, retry, or some other function) ;)

Best regards,
Clemens

Hello Clemens,

Thank you for your reply,

I see, indeed, I understand how this could be useful.

Unfortunately, I'm afraid this is not currently possible in RDM. I'm unsure if this could be implemented due to the fact that when launching a session in "External" using RDM it is simply being started using command lines.

I've opened a ticket to our engineering department so that they can investigate this matter, I will keep you updated with any news I receive but I am not optimistic this will be possible.

Best regards,

HI Samuel,

thanks for this! I also told about this issue our Customer Success Manager, Jean-Sebastien Goyette, when he asked me about our satisfaction with RDM ... not to bypass you or the thema in the forum - just to answer our opinion and to get help for our problem ;)
He told me, that he well 'discuss this with our team and get back to you as soon as possible.' - just to let you know the actal facts and maybe not to discuss this twice maybe ...

Thank you very much!

Best regards
Clemens

We're running into the same issue, trying to get our OT team using the tool. They have to use jump hosts a lot more than our IT team has been, so we haven't really had to deal with this up until now. I'm just wondering why hitting the "reconnect" button couldn't simply resend the command to start the application again.

Sorry, I know this is an old thread, but just wondering if there's been any more movement on addressing this issue.

Hello,

Thank you for your reply,

I've reached out to our engineering department to see if they had an update regarding,

I will keep you updated with any news I receive.

Best regards,

Hi all,

So this is what I discovered this morning.

First some background on RDM Jump. RDM can either send the jump commands directly to the RDM or to the RDM Agent running on the jump host (jump box). If RDM is running and connected we always send them to RDM (no Agent middleman). In the case where RDM is not running they are sent to the RDM Agent and depending on the type of command RDM Agent will launch them directly or dispatch them to RDM (which may need to be started) and all is good.

So what is the issue here? Entries launched directly from RDM Agent do not have the capacity to manage the lifetime of the entry (close/notify close). We will need to address this. In the meantime, if you manually start RDM on the jump host, prior to launching your first jump session, all should work as expected.

I hope that this can, at a very least, help you move forward while we implement a permanent solution.

Best regards,

Stefane

Right-click on the session tab > Agent Status and you will see if RDM and/or RDM Agent are connected.

I've fixed the issue. It will be available in the v2023.1.11 release (next few days).

The fix (new RDM) must be installed on Jump Host (box). You will see RDM start along with the first jump entry. This is due to the fact the RDM needs to be running to communicate with the client RDM to allow close notifications/actions (and others) to take place with the external session.

Note if you are not yet on v2023.1 (DB upgraded required) you could only upgrade the Jump Host (RDM) and not the client RDM and things will still work for you.

Please let me know if the fix works for you.

Check here for the release of the v2023.1.11 https://devolutions.net/remote-desktop-manager/home/downloadenterprise

Best regards,

Hi Stéfane,
we installed v2023.1.13 now (on client and Jump Host), RDM is started with the first jump session but for example external HTTPS connections or NetSupport Manager connections were not closed as expected.
Best regards,
Clemens

P.S.: connections remained with status open in the screenshot attached: 1 = HTTPS, 2 = NSM

Hi Clemens,

You are correct and I can reproduce the same behaviour. This is odd, I will need to investigate and fix the issue.

Sorry for the inconvenience.

Best regards,
Stéfane

Hi Clemens,

After further investigation and a discussion with the dev team. Monitoring external web sessions is impossible to do via RDM. When we launch external entries, we can usually follow the process (process ID) that was started but the thing with web browsers is that they launch a thread (sub-processes) and we don't/can't get a handle to it so we are unable to determine the lifetime of the session.

When it comes to jump, we should probably never even identify the process as running on the client side since we can't actually determine and/or control the lifetime of the process.

Your only option is to use embedded sessions since with these we have full control on the lifetime.

Best regards,

Hi Stéfane,
ok, I understand. Then - as already mentioned earlier in this posting - it should be possible to manually 'override' the blocked active connection by a close, disconnect, reconnect or whatever function. (Otherwise the whole jump host connection with all open sessions has to be closed!) I think this should then be the solution ;)
Thank you!
Best regards,
Clemens

Correct, that part of it we will need to fix. I've logged the ticket to be triaged and fixed.

cool! ;) Thanks!

Hi!
'Implemented' 'status' in the headline / ticket description doesn't mean that the fix is implemented in the actual version (2023.1.28.0), does it? I couldn't find anything about it in the release notes and I just tried it in RDM ...
thx!
Best regards,
Clemens

Hi Clemens,

I'm not sure how the status is implemented, I will need to check with the forum team to validate.

As for your ticket, I can tell you this. While investigating this issue I logged two tickets.

The first, which is currently fixed, has to do with launching external applications (say external RDP) via Jump. You had the same behaviour as what you are seeing. That is, you couldn't close the session or detect when it was closed.

The second is when launching external URLs. Since we launch them via the protocol handler (same as doing Windows + R, typing "https://www.google.com/" and hitting Enter). This causes the OS to launch the default browser to the given web page. With this method RDM doesn't have a window handle to the running process and without it we are not able to close or detect the running state of the session. This part of your issue is still pending and we currently don't yet have a solution for this issue. The only thing we could offer is the option to right-click > close the session in the tree to mark the session as closed but not actually do anything.

Best regards,