Thoughts from the EPS Windows Server Performance Team
Happy New Year! We're starting off 2008 with a significant post regarding changes to Remote Administration in Windows Server 2008. OK, it's not quite as dire as the title makes it out to be, but this is quite a significant change. If you recall from our post on Session 0 Isolation, users can no longer connect to Session 0 on Windows Vista or Windows Server 2008 by design. On earlier builds of Windows Vista Service Pack 1, if you run mstsc /? from the command prompt, the following screen is displayed. Note the section in red below. If you use version 6.1 of the Remote Desktop Client included , in order to connect to the console session for Windows Server 2003, you should use the /admin switch instead. RDC 6.1 is included with the following operating systems:
The /admin switch allows you to connect to an administrative session for Windows Server 2008. As indicated above, it also connects you to the console session on Windows Server 2003. If you are running Windows Server 2008 or Windows Vista Service Pack 1 or later, the following scenarios will return this error message:
So why is this important? Obviously if you have shortcuts, applications or scripts that rely on the /console switch, they will be affected by this change. One of the biggest impacts will be for administrators who connect to their servers using /console to perform application installations or maintenance. This functionality will still be available, however you will just need to use the /admin switch. There are also implications for developers who use the ConnectToServerConsole property of the IMsRdpClientAdvancedSettings interface. There is a different interface and property that they will need to use - namely the ConnectToAdministerServer property of the IMsRdpClientAdvancedSettings6 interface.
The Terminal Services team has posted more information on their blog - the link is below. As always, we welcome your feedback. Until next time ...
Terminal Services Team Blog: Changes to Remote Administration in Windows Server 2008
- CC Hameed
Does Microsft hate Windows users? If no then why keep messing things to make the Windows users lives harder for no apparent reason?
mstsc /admin works now in 6.1 but .rdp files fail
Went back to XP service pack 2. Now my system works like it was designed. The "connect to console" setting in my RDP Snap-in actually connects to the desktop--instead of doing nothing.
I'm okay with you're changing it for some future release of windows--but its downright BAD to remove features--especilly without some way of telling a user that a feature has been removed.
Maybe in the future you could consider another approach to security besides "if we can't secure it disable it".
This one small change has cost me a considerable amount of time and pain.
I almost have a heart attack after I installed XP sp3.
I constantly monitor server to see the console screen again on my XP box.
I almost thought the only way to see my console again is through a Linux desktop before I checked this page.
Thanks a million for the one removed the "console" switch. Now I know my heart is pretty strong. ..
This also applies to Windows XP SP3. I just upgraded to SP3 and the /console option does not work on SP3 also. I had to /admin
How does this affect the Rmote Desktops mmc plug-in? I use this interface to manage my systems. It does have a connect to console check box, however even with it checked I do ont seem to connect to the console session.
Man why change it? Seriously. I have been struggling with this for months now, wondering why my shortcuts and even typing in mstsc /console for YEARS has intermittently stopped working.
Now I see why.
I admin various XP and Win2k, Win2K3 boxes so now I have to type in which switch based on which O/S I am at, and which host I am connecting to then cross my fingers and hope it works????
DID THIS REALLY NEED TO BE CHANGED? IS THERE A SINGLE TECHNICAL REASON or is it just the right hand does not know what the left hand is doing over there?
I have been struggling with this switch until I discovered this web page today. (still attempting to use /console) Why not put up a message in the new client when the old switch is used -- e.g. "/console no longer supportds... try /admin"
What was the point?
I'm really curious why this had to change, please explain. The article mentions 'console session' and 'administrative session' and 'session 0' without any further attempt at explaining the difference and when to expected one or the other.
There's a link in the first paragraph of this post to a previous post we published that discusses Session 0 Isolation. There is a link at the end of this post to a post on the Terminal Services Team blog (Product Group) that discusses Console v Administrative sessions.
Hey CC - It's Kristal. We are trying to find out if there is any way to use tsmmc.msc to connect remotely with consoles now with RDP 6.1 in place. There is no /admin capability that we know of using the mmc.
Ditto the comments made by "Ben" on 5/13/08 and "Interested Bystander" on 01/15/09. My site also had production problems related to running two copies of an application because some of us (who had been upgraded to XP SP3) were still using the /console switch.
Changing the name of the switch would not be so bad if MicroSoft had not been so SLOPPY and just taken the time to properly QA their software. Since /console is not supported, that switch should generate an error message and not connect at all, instead of letting you proceed thinking things are working as expected.
I need access to Session 0 - how are you addressing to breaking the ADMIN requierment?
Beginning with Windows Vista, Session 0 is non-interactive. If you refer to the post that we wrote earlier on Session 0 Isolation, we cover that. The ability to log on to an administrative session via RDP still exists - you now use the /admin switch, and not the /console switch when making your RDP connection.
I had been completely lost as to the reason why I could no longer connect to session 0. Thanks for this, you have made my day.
By the way, we're going to rename /migrate to /move. Don't worry, it will do the exact same thing, except the name of the command you've been using for years is different, and in mixed environments you get to troubleshoot problems related to accidentally using /migrate, which will be made more difficult since /migrate won't throw a flag when it doesn't work. Also, don't forget to change your scripts!
Can someone give me a better reason for the change? Anyone?