"Connect when available" and "Altenate host"

Hello,

Thank you for contacting us on this matter!

I would like to verify, just to verify if the issue could be tied to the use of the $COMPUTER_IP$ variable, if the same issue occurs when you enter the actual IP directly in the Alternate Host field?

Best regards,

Hi

I have tested with the IP directly, and it doesn't make a difference.

On the other hand, if I "Connect when Available" to a server which is "Available" so the initial connection is established to the alternative host, and I restart the server, the retry appears to remember that it used an alternative host.
But if I shut down the server, initiates a "Connect when Available" (And of cause the hostname isn't working), the retry appears to only retry on the host and not the alternative hosts, meaning that if I then starts the server, the retry never finds that the IP is alive.

Hopes the narrows it a bit down :)

/Lars

Hello,

Thank you for your response! In that case, let me see if I can replicate his issue on my side to report the problem to our engineering team.

Best regards,

Hi

What is status on this?

Regards

Hello,

While we haven't been able to replicate this issue at this time, I will have a discussion with the agent in charge of this thread and get back to you with our results.

Best regards,

Okay.

I can easily reproduce, so if any questions please just ask.

/Regards

Hello,

I'm really sorry, first of all for taking quite some time to get back to your issue and also because I still can't replicate the issue. I seem to be missing some information or a step to replicate. Allow me to ask you some questions that I realize I should have asked some time ago, hopefully it might help me find the missing piece to trigger your issue on my side.

• What version of RDM do you currently use?
• What type of data source do you use?
• Could you please reiterate what exactly is the difference for when "Connect When Available" works, and when it doesn't work?

Best regards,

Hi

No worries, you guys are still awesome! - And I know that you need that information, so I could have been more detailed in my post :)
So I have just added it to my signature :D

I always update RDM when I am notified, so I'm running now running RDM 2022.2.24.0 64-bit and I have tested and verified that the bug is still present.
I'm connected to DVLS as datasource.

To replicate:
Create a new folder, choose that the folder is a Server, fill out the Hostname with something non-existing and the IP address with a working IP, for a turned off server.


Under this folder, create an RDP connection, where host is set to inherit

Still in the RDP session properties go to "Description", set "Alternate host" to "Port Scan" and enter $COMPUTER_IP$ in the textbox.


Now, with the server still powered off, start open the session with "Open when available" and wait for the retry windows to open.



Now power on the server, and you should "hopefully" see that the retry windows still reports "Waitng for host".

And for a final test, close the retry window, and try again to verify that you can connect to the server with this RDP Session, and by that verifying my statement.


My main goal here with the above setup, is that no mater what "errors" occur when trying to connect, it should spawn the "Retry window" and retry connection both on the Host and the Alternate host's list.
Whether it is retrying both things each "Waiting for host" or switching something like:
Waiting for host... (Port Scan against Host)
Waiting for host... (Port Scan against Alternate Host 1)
Waiting for host... (Port Scan against Alternate Host 2)

or

Waiting for host... (Port Scan against Host)
Waiting for host... (Port Scan against Alternate Hosts)

Is not relevant for me, for me it's just what's easiest for you :)

Hope this helps, as I can see that this should have been what my first post looked like :)

Regards Lars

Hello,

Thank you for your additional description! I did some tests, and I would like to share the results of my test, as I'm now pretty certain I understand your behavior but still can't replicate it.

I configured my Server folder and RDP entry as you described, using a non-working Host and a working IP address. I used a VM to test, which requires a VPN to access it so I could easily enable and disable access to it.

With the VPN on, launching the RDP session normally works of course, using the IP address after the bad Host fails.
With the VPN on, the "Connect when available" button also works, using the IP address to connect.

With the VPN off, if I click on "Connect when available" button, I get "Waiting for Host..." messages periodically. The moment I turn the VPN back on, the connection is started using the alternate host IP address.
I believe this is the behavior you are looking for and, on my side at least, it seems to work as expected. It may not be indicated in the "Waiting for host..." message, but it does look like it also uses the alternate hosts.

Best regards,

Hi

I have uploaded a screen recording to showcase my issue, to you sharefile.com. I hope we are misunderstanding each other else I think it's very strange you can when I can't :)
The file is called 37777-connect-when-available-and-altenate-host.mp4

Hope this shed some light on the problem.

Regards Lars

Hello,

Thank you for sending us the recording! I will contact our engineering team to see if there might be logs we can gather to get more information about what is going on on your end that prevents the reconnection using the alternate host.

I will get back to you as soon as I have their response!

Best regards,