Hi Timothy,

Let me first start by saying I am a big fan of RDTabs and I recommend it to everyone I know. One issue that plagues me and others I know that use the product is the issue where we drop our TS sessions all the time. Now this is not due to a TS Sessions idle timeout setting in the user profile or a TS configurations setting, its just RDTabs at any given time will drop a session... sometimes just one, other times a handful of sessions.

At any given time of the day I can have 10-15 tabs going. When I come in in the morning, a handful will be there greeting me with a reconnect message... and again, just a handful, not all. So what we did was open a non-console session to a server with MSTSC and another on the same server with RDTabs and just let it set there. Went to lunch and when we came back, the RDTabs was greeting with a reconnect message while the MSTSC was still connected just fine. A couple servers that I have never drop my session - I've been idle on the boxes for days and RDTabs has remained connected. As far as network stability goes, there is no physical topology difference between the servers from which I drop TS sessions and those that stay running all the time. This is an issue I've had for most of the two years I've been using the tool. Now I have never had RDTabs drop a session while I was in the session working (barring a network issue)... that is always stable, it's only when I leave session idle.

Now when reconnecting to sessions in RDTabs, it's about a 50/50 shot whether I reconnect to my previously disconnected session, but I can live with that by connecting to the other session while on the server; it's probably more TS than RDTabs.

Anyway, still a great product that I will continue to use, but thought I would ask about it.

Any thoughts on that or do you experience similar behaviour?

RD Tabs uses different code to automatically reconnect on network failure than the MSTSC. RD Tabs used to use the built-in reconnection code, but (at least as of RDP 5.2 and 6.0 - haven't tested 6.1), it was buggy as heck in the COM control -- to the point it would sometimes crash RD Tabs. I may explore this option again in 6.1 and see how it works. Maybe they fixed it. MSTSC, being standalone, doesn't suffer the same bugs as the COM control does.

Anyway, the RD Tabs way requires a username and password to be entered to re-establish connection to an existing session. If not, you will receive the logon prompt, and after the time-out, it will dump (back to the disconnected screen).

I suspect network issues because MSTSC will survive this since the API will reconnect without knowing the password (it, I presume, looks for the existing session based on some sort of encryption secret both sides share - I don't have access to this level of the API). So, after lunch, you'll see MSTSC connected and RD Tabs disconnected.

Try entering the username/password in the connection properties box and see if it still dumps on you.

As for not connecting to the same session, this further makes me think network issues. What's happening on the server is it still thinks RD Tabs is connected even when it's not, so when the new connection is established, it creates a new session. This can be mitigated by setting the property in group policy (or directly in the terminal server properties) to only allow one session per user. The remote server will detect the new session and reconnect you (effectively disconnecting the session that was dropped, but it didn't know it yet).

Thanks for the reply. I suppose it could be network - I really can't prove otherwise. I shy away from it being a network issue because a couple reasons. As mentioned before, topographically there aren't any differences between the servers that drop and the servers that remain connected. MSTSC doesn't drop and you've given your thoughts on that, but running RD Tabs side by side with mRemote on the same machine and each with a TS session to the same server, I do not get any drops from mRemote and I would presume they have similar API access. Anyway, I still prefer RD Tabs (screen capture by region is phenominal) so I will continue to plod through it. Thank you for the information.

Weird. I may be wrong, but the only feature I explicitly disabled (due to bugs) was the automatic reconnection feature. The remote connection API is the Microsoft RDP COM server, so yes, it probably is the same API as mRemote (I haven't dug into that software, so I can't say for sure). It is very bizarre that you'd see it in RD Tabs and not mRemote. I didn't write any protocol-level code, so I can't control that, unfortunately. 😞 I have seen differences over the years between MSTSC and RD Tabs and from what I can tell from digging into it is that MSTSC does NOT use the COM server, so that would explain why there are subtle differences between RD Tabs and MSTSC.

I'd love to be able to fix this for you, but it's probably out of my control. If you could somehow put together a test case, I might be able to do something. Keep my updated on this.

So far, I've never noticed what you describe.

One question -- do you notice this behavior on other PCs? Maybe the RDP COM component needs to be reinstall/re-registered/etc...?

Yea, don't sweat it, it could totally be something related to our environment. If you haven't seen it and those browsing the forums haven't chimed in, it's probably our environment.

I don't really see it at home, but I only have a couple servers that live on the same switch as my home PC whereas at work, there are access layer switches, cores, routers, etc involved in data paths. One other engineer uses it on his machine and sees similar behaviour.

Regardless of this anomaly, great product, and considering what I pay for it, I get a great return on my investment. :)

Take care,
Kevin

For 2.2, I'll see if I can add an option to use the built in auto-reconnect. It's very possible that it may enable some sort of increased network fault tolerance, in addition to reconnecting fully dropped connections.

In fact, I think I will compile out a test build for you with that feature hardwired. RD Tabs may act weird in a true network drop autoreconnect situation, but it would be worth testing to see if it helps it with network stability for you.

It wouldn't be the first time Microsoft had incomplete API documentation. 😉 It will only take me a minute to set up the hardwired flag. Shoot me an email on the contact form (reference this forum link) and I'll email you a debug version of rdpcontrol.dll.

Then at least we can rule out that as a cause.

Will do.

Another question... if I connect to a host using a populated connection properties (user name, password, domain) and the "redial on connection failure" is checked, shouldn't it be able to log itself back in as opposed to asking me to reconnect?

The redial option only invokes while you are connecting and receive an error. For example, if your remote computer is rebooting, you can check that box and it will redial until it connects (like dialing a busy BBS in the old days). However, if you disconnect after establishing a connection, redial has no effect.

Heh... BBS.

Anyone got time for a quick game of TradeWars? 🙂