Terminal Services Team Blog

I'm still sad that TS Gateway won't be included in Vista.

Este es un resumen del articulo publicado en Terminal Services Team Blog , en donde se describen las

what is "physical console"? without this I couldn't understand most of the article?

It's not very clear to me from the article, so I'm hoping someone can answer.

Currently in Windows Server 2003, we can actually have 3 TS sessions -- 2 normal ones plus the console, which has come in handy on occasion when 2 administrators have accidentally left sessions running. One can always usurp the console session, which is often easier than trying to use TS Manager to disconnect the other admin sessions.

Is this still the case in 2008 or are there now really only 2 sessions?

The Terminal Services Team blog has a good post about these changes. One of the most obvious changes

Sergey,

Thank you for the info. That sounds like a really well done change.

Perhaps the title of this post should be "Microsoft decreases the number of concurrent remote admin connections in windows 2008"

That's a lot more important than the functionality "gain" that is presented.

The main use my team has with the 3 sessions is troubleshooting issues on the servers.  To limit the number of concurrent sessions simply cripples these efforts.

The added functionality of allowing more disconnected sessions seems like a good way to waste more memory.  Perhaps this is good, I'm just pointing out a side effect.

Also, I'm struggling to understand the benefit of changing the command line switch for GUI based tool?

Sorry for the sarcasm, this "enhancement" is frustrating.

Bron: bink.nu Uit testen blijkt dat Windows Server 2008 RC0 erg veel sneller is dan de voorganger Windows

Forcing users, even admins in this case, to relearn a command for no good reason is really a waste of everyone's time.  There is no reason that Server 2008 couldn't just interpret the /console switch as "/admin" and be done with it.

Even better for users (admins) is that Microsoft in their wisdom will either silently ignore the switch (CLI) or posting a vague error, “An unknown parameter was specified in computer name field.” (GUI).  

If we REALLY have to change the switch, which I'm obviously not convinced makes sense at all, then wouldn't it be a nice idea to print out the usage parameters rather than fail silently, or in the GUI, I dunno, provide a link to a local help file that explains these changes?

I can understand that from Microsoft's point of view this should help some application run better than rely on being run in session 0, and I've seen a handful of such applications; however with 5 years of time for application vendors to correct the issue, this change seems to be a bit late.

In regards to the 3rd terminal server connection, I agree that is was definitely useful and I've even seen some instances where, especially SBS users, would use these 3 connections as a mini-terminal server.  These chahnges allow Microsoft to properly wring out every last cent...  err license features to those who need it.  

Seriously though, to a user (or again admin most likely for this case), the only potential benefit is that you might not break a handful of applications that require session 0, everything else is an annoyance.  i.e. relearn command switches, lose 3rd remote session, lose ability for small customers to use server for a handful of remote users without having the complexities with licensing etc. involved with running terminal services in application mode.

From a customer's point of view, I'd give this a C+ and only because of the handful of applications that should benefit from session 0 no longer being redirected.  Outside of that one benefit, from a customer's point of view, this new 'feature' is a FAIL.

'/console' equal 'connect to console:i:1' option in rdp file.

Now, What option is '/admin' in rdp file ?

I understood the rdp file option for /admin.

/console = "connect to console:i:1"

/admin = "administrative session:i:1"

This really suck, wasted hours before I figured this one out...

It is an arrogant move to not make the new option backwards compatible, and just another try at FORCING Vista and soon Windows 2008 down peoples throat...

You should have left the /console option, windows 2008 could easily have ignored this..

Poor job you guys.

Perhaps the question is with all the "positive" feedback here, one must wonder if MS even cares at all.  As with http://blogs.msdn.com/ts/archive/2007/01/22/vista-remote-desktop-connection-authentication-faq.aspx?CommentPosted=true#commentmessage where they got no positive feedback either, it seems like MS has decided that changes that no one likes are acceptable and are becoming common place.  It's like they sit around and ask themselves, 'hey, what can we do to irritate another block of customers today?' and then they brain storm and come up with the most annoying and idiotic changes one could possible envision.

I'm perfectly happy with RDP 5.2 on Vista and won't use 6.0 or 6.1 until MS listens.  The problem is they just don't care and make no $ off the RDP client so they have ZERO incentive to honour the wishes of customers.

Windows Server 2008: Zmena v RDP z hlediska administrace serveru

crosspost from http://blogs.msdn.com/rextang just upgraded my Windows Vista machine to Vista SP1 RTM

So this blog is documenting the changes to Windows Server 2008, and why "/console" is no longer needed in the new server.  Fine.

Unfortunately, the /console option behavior was removed from the CLIENT.  So if I use the new client to connect to a Windows Server 2003 server, I STILL can't use /console.  Forget the fact that there really, really, really is a physical console session on Windows Server 2003.

I'm agreeing with the other posters.  Symbolically, /console==/admin.  Session 0 is an irrelevant implementation detail.  The client should either give an error to the user for /console, or support both options with the same behavior, or both.

The decision to remove support for the "hidden" admin connection isn't such a big deal, but I can understand the cause for complaint.  Instead there is the benefit that *no* sessions get logged out when a 3rd (4th) logs on, they just get disconnected (user switching).  That's a pretty neat feature, and based on many admin usage patterns it may even be a lot more important.

Este es un resumen del articulo publicado en Terminal Services Team Blog , en donde se describen las

Its' really anoyng, i'm using a third party rdp-tool thats uses the /console switch but not the /admin switch.

I'm using this tool to connect to approx 50 Win2003 Server and are not able to connect to the consol-session anymore.

I just trough out the windows my new notebook with Vista SP1 and use my old notebook with XP further.

I don't think that on this way MS can bring us admins to use Vista SP1.

Bring a fix for this immediatly

The OSX version of RDC says: "This beta version of Remote Desktop Connection is out of date. You are using a beta version of Remote Desktop Connection Client for Mac 2.0. We recommend upgrading to the final release version. You can download the latest version of RDC at http://www.microsoft.com/mac/"

BUT THIS IS A LIE! There is no final release version on the M$ site. Why are you implementing a timeout and don't offer at least a replacement version?

Because of this annoying message, my .rdc files for various connections do not work anymore, RDC only remembers the login credentials of a single server now.

PLEASE PLEASE PLEASE offer at least a timeout-fixed version if you are not able to provide a final version.

I'm using Windows Vista (Client) and 2003 (Server). However the bug (or feature?) for playing/recording audio on the remote hardware is still not fixed. It is annoying that the workaround to log on the console (where I can both play and record audio files on the physical sound driver) will not work any longer -- my Vista client does not support "/console" while my 2003 server does not support "/admin".

How can I play / record audio remotely?

Is the only way to remove SP1 on my Vista client?

Will this be the end of my Media Services Installation, or should we offer silent films again?

Anyone have an idea how/when the Remote Desktops admin feature will support using the TS Gateway to connect to servers?

Thanks,

Steven

Who dropped the ball on this one? Removing the /console switch is just plain stupid. Release an update and add it back. I'll be uninstalling Vista SP1 from computers for the rest of the afternoon.

For the people that don't want to remove Vista SP1 or XP SP3 just replace the new TS files with the old ones. The two needed files AFAIK are mstscax.dll and mstsc.exe, and you can find them on system32 dir (XP).

This was a poorly thought out plan.  The changes break most 3rd party RDP utilities.  Why not leave /console as a valid switch and just interpret as /admin where applicable?  Lame job by the MS team.

This was a bad decision. /console no longer works on XP SP3.

Do you guys have any idea how much sysadmin time is going to be wasted because of this idiotic decision?

Do you think those system admins will be happy or upset?

I am using the Remote Desktops snap-in from the Windows 2003 Server Admin Tools, just like many other Admins here, to connect to several servers to the console, Session 0.  I don't think that Microsoft realized what problem this will present, not to also issue an update for this tool at the same time when the issued Service Pack 3 for XP.  Millions of admins around the world will be really, really mad!

I have to waste time to re-configure all my remote connections now using the Remote Desktop included with XP, which I don't like because it doesn't offer me the same efficiency and speed in my remote work on the servers.

So "/admin" replaces /console", but what replaces the following .rdp-file argument;

connect to console:i:1

?

I've changed all my shortcuts from /console to /admin, but I don't know what to add to my rdp-files (which uses no shortcuts, hence no command line arguments.)