First, I have to say that RDP 6.1 is a bear. It doesn't install nor register the same as 6.0 and earlier versions. It has a crapload of dependencies that REQUIRE Vista SP1, XP SP3, or Server 2008. So, unfortunately, 6.1 will remain a post-2008 Service Pack feature ONLY. RD Tabs will, for all non-compliant systems, revert to the included RDP 6.0 library. For RDP 6.1, RD Tabs will use the SYSTEM installed RDP library (the one in system32). This is a permanent change going forward to provide maximum features for new systems, while remaining backward compatible for older systems.

If you do not meet the service pack prerequisites, about the only thing you are missing (other than a few Microsoft-provided UI enhancements in modal dialogs) is Terminal Services Gateway support. There is supposed to be better compression with 6.1 too, but I haven't really noticed anything breathtaking in my tests.

Since I had to recode the installer and some of RD Tabs' guts, I'm not pushing this one through the beta auto update, until I have a better hold of whether or not the installation is stable.

Thanks for all the help testing this.

Here are the links!

x86: http://www.avianwaves.co...-DO_NOT_REDISTRIBUTE.msi 
x64: http://www.avianwaves.co...-DO_NOT_REDISTRIBUTE.msi 

Here's the changelog...

- RDP 6.1 Good news: RD Tabs now supports it! This version now supports Terminal Services Gateway!
- RDP 6.1 Bad news: It will only work in post Vista SP1, post XP SP3, and Server 2008 deployments... Also, it seems to be slower now when you connect to your first session. This also happens in the mstsc.exe (Microsoft's version), so it's not unique to RD Tabs. I guess it just has more overhead than before. I ran ProcMon during the one second additional wait and it hits thousands and thousands of registry entries (speculating that may be the cause of the delay). Sigh. It's not too terribly noticable, just annoying. And there's nothing I can do about it.
- RDP 6.1 Details: The 6.0 control is included with RD Tabs for legacy deployments, but 6.1 (due to many changes in the underlying control and deep library dependencies) requires the latest service packs (Vista SP1, XP SP3, Server 2008) to work. The libraries are included in Microsoft updates. RD Tabs will no longer contain the latest RD control because of these backward compatibility issues, but will instead rely on Microsoft and Windows Update. XP SP2 and older systems will have the RDP 6.0 libraries automatically installed. Vista and later will not, but will instead use the Windows built-in versions.
- Really fixed the drawing bug in the status bar this time. I guess I should check my bug fixes before saying they are fixed in the change log. :-)
- The afforementioned Resource Manager now has a more benign non-error message when it is not on display (it's a canned message, what can I say?) so that if you peak at it using a tool that can "see" hidden windows (such as the thumbnail task switcher powertoy for XP), it doesn't freak you out with an error message that isn't actually happening.
- The "About" dialog now includes a little more diagnostic information (mainly only useful for me): number of open tabs and number of tabs that are cached for later reuse.
- "Disable Remote Desktop Protocol compression" was moved to the "Experience" tab to make more room in the "advanced" tab for new Terminal Services Gateway options.
- Terminal Server Gateway options are now available, but may be buggy because I do not have a TS Gateway to test with. Please test this for me!
- If an extended reason (descriptive text) is provided by the remote desktop control for previously unidentified disconnection codes, you will now be able to see that text, even if RD Tabs is not aware of what the problem is or why it occurred.
- Not all TS Gateway disconnection/error codes are programmed (I couldn't find a list and cannot currently test scenarios). Please report the disconnection code number and any descriptive error text provided, if you discover a new one.
- Fixed a bug in one of the lightweight label controls where text wouldn't wrap properly in some cases.
- Updated the batch editor to support Terminal Services Gateway settings.
- The policy checker module will disable saving of gateway passwords if Remote Desktop is set to not allow saving of passwords.
- The RD Tabs "allow password saving" option must be enabled to allow saving of gateway passwords.
- Fixed some typos.
- Added a maximize button to the batch editor interface.
- Streamlined the look of the batch editor for under Vista (some of the controls drew off-center and looked funny).
- The Remote Computer Information's ping tool was reporting inaccurate response times on some systems (notably very innaccurate on Vista systems). This has been fixed. Additional error messages may appear as well, such as "unreachable" or "TTL Expired" when applicable.
- You can now change the ping timeout in the Remote Computer Information tool on the fly now by clicking on the "Set Timeout" link (good for high latency networks). I'll probably move this to the application Options eventually, but this is just to get this feature in place for immediate use. Default (and minimum) is 500ms. Not sure why, but any value under that is ignored by the framework's ping command. Also, no matter what you set the timeout to, no more than one ping per two second interval will be sent out, in order to avoid ping-flooding remote servers. This bug occurred as a result of the new, more responsive, disconnection code.

Not sure if I should post it here, but I've seen a delay in the controlbox of the application (Minimize, Maximize, Close) since beta 2.1.2.

Whenever I use one of the controls, the application freezes for about two to three seconds and only then responds to the request. Mouse gets frozen, too.
This was not so in alpha 2.1.1.

Aside from that: Great program!!!

I've never experienced that problem before. Are you able to reproduce it on other computers? Do any other applications exhibit this behavior? If you uninstall 2.1.3 and reinstall 2.1.1, does the problem still happen?

Thanks for the new version.

Installed Vista SP1 today - and saw that RD shortcuts must now start with /admin instead of /console
for connecting to a machine in console mode.

The Console setting in the RDTabs favorites unfortunately seems to be having the same problem - as I cannot
connect as Console - it connects as a regular connection even though checked.

Is there a special way I can get this to work in 2.1.3 ?

Good catch. I'm actually not sure why it's not working. The API call is the same, as far as I know. I'll have to research this. Also noticing that Remote Computer Information is not always able to obtain remote desktop session information, even with administrative credentials. Although that might be a Vista elevation issue.

Just Googling - but this might help:

"
Changes to APIs
If you are using RDC 6.1, you can no longer use the ConnectToServerConsole property of the IMsRdpClientAdvancedSettings interface to specify whether the Remote Desktop ActiveX control should try to connect to the server for administrative purposes. Instead, you must use the ConnectToAdministerServer property of the IMsRdpClientAdvancedSettings6 interface to connect to one of the following sessions:
• The physical console session on a Windows Server 2003-based computer
• The session that is used for administrative purposes on a Windows Server 2008-based computer

For more information about the ConnectToServerConsole property, visit the following Web site:
http://go.microsoft.com/fwlink/?LinkId=106203  (http://go.microsoft.com/fwlink/?LinkId=106203)
For more information about the ConnectToAdministerServer property, visit the following Web site:
http://go.microsoft.com/fwlink/?LinkId=106204 
"

From http://support.microsoft.com/kb/947723 

You got it! Thanks for the heads up. Why they changed the nomenclature and API, who knows.

I also discovered that the problem with the remote sessions in the Remote Computer Information is very complicated, but it seems to boil down to that you can't call the API too soon after already calling it. Plus, you have to be elevated if UAC is enabled. So I had to insert a delay and also add UAC detection. This problem and the connect to console problem will be addressed in 2.1.4, which will be out later this week.

Soap - In your reading, did you happen to read if Server 2008 machines will allow multiple simultaneous administrator sessions? Server 2000 and 2003 allows three (one console, two terminals), but the quote up there almost makes it sounds as if there will only be ONE remote connection available...

Pleasure.

I was also a bit confused around the nuances for multiple connections etc. So no, will have to see with experience. Have got the 2008 MSDN ISO to install and try - just haven't gotten around to it
yet.

Soap - Found a link explaining the changes on the Terminal Services blog. The /admin flag makes more sense now to me.

The short:

/Console logged you onto "session 0" in 2003 and older. Since "session 0" is reserved for services in Vista and Server 2008 and interactive sessions start at 1 for remote desktop AND local logons, /console was deprecated. /Admin logs you onto "session 0" ONLY on Server 2003 and older systems as a form of backward compatibility. For 2008, it has no effect UNLESS you are running a full terminal server, in which case /admin will bypass license checking and a few other things, so you can get into the machine and administer it. It also requires you to be in the "administrators" local group, so it can't be used by any standard users. Again, for non-terminal servers, /admin is ignored.

Finally, only two simultaneous logons can be used in 2008. This is the same as 2003 except that the "console" logon served as a third logon as long as nobody was sitting at the console (common since machine rooms are frequently far from admin's desks). From what I understand, you can still have three logons (one console, two remote), but there is no way to use up the console logon remotely anymore, like you could with /console. The console logon (which can be any session number) can only be used at the physical console. This kind of sucks because some of the developers at my company can remote desktop into our 2003 boxes for simple file-based administration of their respective web applications (not in the administrators group) but if I needed to get in for an emergency, I could just use the console session without having to kick anybody off. No more! In fact, it seems you might need terminal server licenses to let any non-administrator in, but I haven't been able to check if that was true. You weren't supposed to be able to with 2003 either, but if you added extra groups to the "allow remote desktop" security option or added domain groups to the local Remote Desktop Users group, you could get around that limitation. Not sure if 2008 is the same or not. (Sometimes when Microsoft says you can't do something, you really can, it's just not supported lol.)

Here's the link with details...

http://blogs.msdn.com/ts...windows-server-2008.aspx