Hello ​@Rohit Nikam - I think the best course of action is to generate some logs from the affected Jumpoint and then log a case with those logs with our Support Team. Typically, our logs will outline the reason for the dropped session.

Hi Phill. Thank you for your reply, I have already created a case along with all the logs and Support team mentioned that This issue has been raised by a few other customers around BYOT RDP jumps and currently the cause of the issue is being investigated by our Tier 3 and development team to try and find a resolution. I am hoping to get this resolved asap. 

But The reason behind my question to be added here is that I wanted to check if there is any other workaround/options I can get here from any other customers who faced this issue in past. Thanks.

I saw in Remote Support’s 24.3.2 release notes solving issues with BYOT RDP, but I don’t know if it is related to your issue:

Hi Phill, Thank you for sharing this, I will check once with our TAM and confirm.

We have seen what seems like the same exact issue in our environment too! I’m so glad to know we are not the only ones. We are currently on PRA 24.2.3. The major thing we have narrowed it down to is when the client/user’s PC is on Windows 11 and the remote system is on Windows 11. Windows 11 has a different version of remote desktop (see screenshots below with Win10 and Win11. We have found that it is related to the client PC’s RDP version and whether or not NLA is enabled on the remote system. 
 

We are really hoping this fix listed in the release notes for 24.3.2 fixes the issue. We are in the process of installing this version in a test environment now to see if it is fixed.