(workaround) Microsoft RD Gateway - Hangs ASG

[whynotpizza]

Ok guys,

Revisiting a very old thread in hopes to convices the team at ASG to help resolve a fundamental issue which Microsoft has agreed is a bug in their code by has yet to provide any solid path to resolution.

OLD THREAD: https://remotedesktop.rocketsoftware.com...?tid=10460

When you use ASG software on Microsoft systems, and RDP connect machine to machine using a Microsoft RD Gateway in the middle, the ASG tool will hang. This is proven with vanilla Microsoft code. Turns out the "mstsc.exe" process attempts to make a direct HTTP call to akamitechnologies (not using any proxy). So if your company blocks this kind of traffic, ASG will hang, since the underlying thread of mstsc.exe is hanging attempting to make a call via HTTP directly.

My ask is that the ASG team provide a simple workaround by allowing the force close of the mstsc.exe process on session exit. This would eliminate the problem.

Yes, ideally Microsoft can and should fix this issue. But as we have demonstrated (going back 5 years ago and still to this day) they have yet to resolve it.

Please help.... we love the ASG tool and want to continue using it, but it is causing huge pain for session disconnects in our environment.

Thanks for considering this request.

  David

[DevOma]

Hi

I don't think that is done by a "small workaround" - there is no event for "start disconnecting" - so we had to use user action like close window/tab to "kill" the process - we can reset the object in code that is used for creating the ActiveX - but that could also run into any code parts of the ActiveX - and killing ActiveX might cause some new problems with memory or existing processes?!? Nobody knows - so not quite good implementation so far...

I understand that it is really annoying for you - MS confirmed a bug but don't fix it - but your workaround has also some risks - and currently we can't test it because we do not have this issue?!? Wouldn't it be easier to allow the http connection to akaimai? Don't know why this is implemented and why we don't have this issue? But must be something that you could also resolve by network settings?!?

[whynotpizza]

Turns out our firewall restrictions do not allow a direct HTTP call to infinite numbers of destinations of akamaitechnologies.com (the URL is different each time) as a result, there is no way for us to change firewall infrastructure to work around this problem. We cannot open up *.akamaitechnologies.com" for example, nor do we want to from a security perspective.

RE testing (understood), although setting up vanilla RD gateway services on an internal loop and restricting firewalls rules to prevent any call outside the local network isn't too difficult to setup - this is what we did to isolate the issue using VMware images of vanilla microsoft operating systems and software.

How about this instead ...

Any chance you guys would be willing to build an optional test image which has a flag which would do this thread-kill on exit if the user chose? We would be happy to test a sample code base to see how it behaves and if this looked good (no adverse affects) you could consider rolling this as an optional configuration parameter in the connection setup.

Just a thought, we are struggling here and any option at this point would be great.

We have hundreds of servers being managed and as you can imagine patch updating is a ton more overhead we ASG hangs waiting for 1 min or more on each session disconnect due to underlying problem with mstsc not disconnecting properly with gateway enabled.

[DevOma]

Hi again :-)

it's not that we do not like to implement such features - we would do if it make sense - and of course for you it makes sense :-) But in this case the "how to" is the main problem...

Sounds really easy to just "kill the process" - but have you looked into it via Process Explorer? There are a lot of threads running even with 1 connection - and how to determine on many connections which thread is related to a specific connection? I don't think that there is an easy way for killing the right process - or do you have a detailed plan for that?

I don't think that it will be enough to "reset the used ActiveX object" instead of calling "Disconnect" - perhaps we can try with a smaller solution but I guess that it will execute the same code inside the ActiveX control - let me spend some hours on this...

[DevOma]

I read the old thread again - and there was a suggestion from another user that in mstsc.exe the floowing setting "Experience => Detect connection quality automatically" could solve this problem?!? Did you ever checked that with mstsc.exe? I have analyzed the code and there might be bug in the code regarding this setting?!? I could fix this and provide a private fix - but of course it would make sense to know if you see the same behavior with mstsc.exe if you set this option?!?

We are trying to setup a test configuration - but as we need a RD-Gateway it will take some time...

Does the problem occur only on "Disconnect" or also when connecting to a server/client? We have also implemented 2 cmdline options in current dev build - 1. Kill the ActiveX object instead of calling "Disconnect" - and "Call Disconnect in own thread" - so the current thread should run without waiting?

[Michael Scholz]

...RE testing (understood), although setting up vanilla RD gateway services on an internal loop and restricting firewalls rules to prevent any call outside the local network isn't too difficult to setup - this is what we did to isolate the issue using VMware images of vanilla microsoft operating systems and software...

Could you give me a hint how you setup that internal RDGW environment & what you used to be able to retrace the problem ? I would be happy to receive some more infos by private mail to my adress in the footer :-) Thanks in advance and best regards,
 Michael Scholz

[aaron_huber]

I read the old thread again - and there was a suggestion from another user that in mstsc.exe the floowing setting "Experience => Detect connection quality automatically" could solve this problem?!? Did you ever checked that with mstsc.exe? I have analyzed the code and there might be bug in the code regarding this setting?!? I could fix this and provide a private fix - but of course it would make sense to know if you see the same behavior with mstsc.exe if you set this option?!?

We are trying to setup a test configuration - but as we need a RD-Gateway it will take some time...

Does the problem occur only on "Disconnect" or also when connecting to a server/client? We have also implemented 2 cmdline options in current dev build - 1. Kill the ActiveX object instead of calling "Disconnect" - and "Call Disconnect in own thread" - so the current thread should run without waiting?

Using a separate thread for the disconnect process sounds like the best fix, as then it can do whatever it needs to do in the background with zero risk from killing it, but not hang the rest of the ASG window while we're waiting for it.  Is there a way we can test this to see if it works?

We only see an issue when disconnecting an RDP connection that uses a gateway - the entire ASG window will become unresponsive for a period of time.

Aaron

[aaron_huber]

For anyone else experiencing this, we did find a work-around. If you create a Windows Firewall rule blocking the ASG process from outbound connections on TCP/80 then the issue doesn't occur. Checks for ASG updates still work as I assume they are using HTTPS, and we don't connect to anything else in ASG that uses port 80 (at least that we've found yet).

Aaron