This article describes a few behavioral differences between Windows Server 2003 and Windows Server Codenamed Longhorn in Remote Administration mode. Note that these changes will be available in Beta 3 and later builds.
Architectural change - Session 0 Special-ness
In Windows 2003, the session 0 is always associated with session on physical console. When user logs on to physical console or connects remotely using /console, she gets session 0.
In Longhorn, session 0 is not an interactive session anymore. It hosts only services. The first interactive user session is session 1, no matter whether user is logged on to physical console or connected remotely. The second interactive user session is 2 and so on. The session IDs are reused as users log off and previous sessions are terminated.
Reconnecting to session 0 from another session by any means, such as tscon.exe, is denied in longhorn server.
Reconnecting to your session on physical console
In Windows 2003, administrators typically use /console to reconnect remotely to their session on physical console. In Longhorn, /console switch is ignored in remote administration mode. The session obtained by connecting using /console is just like another remote session.
Reconnecting to your session on physical console (or any of your sessions for that matter) is driven by "Restrict user to one session" policy. This policy value can be set using tsconfig (under "Edit Terminal Server Settings" - "General" section). There is also a group policy for this which can be edited using gpedit.msc (navigate to Computer configuration - Administrative templates - Windows components - Terminal Services - Terminal Server - Connections).
The default value for this policy is 1, which means each user is restricted to one session. So, you do not need /console to reconnect remotely to your session on physical console, unless you modify this policy value. Here is the scenario and behavioral difference in Windows Server 2003 and Longhorn.
You are logged on to physical console of the server.
Now you (using same user account) connect remotely to this server.
Windows Server 2003 behavior:
If you use /console while connecting, you will get reconnected to your session on physical console. If you did not use /console while connecting you will get a new session. It does not matter what the value of "Restrict user to one session" policy is.
Windows Server Codenamed Longhorn behavior:
If "Restrict user to one session" policy is ON, you will get reconnected to your session on physical console. Note that you do not need to specify /console anymore to reconnect remotely to your session on physical console.
If "Restrict user to one session" policy is OFF: If your session on physical console is active, you will get a new session. If your session on physical console is in disconnected state, you will get reconnected to that session.
Note that this behavior applies no matter whether you specified /console or not while connecting.
If "Restrict user to one session" policy is OFF and you want to get back to your session on physical console:
PingBack from http://blogs.msterminalservices.org/conger/2006/11/28/console-behavior-differences-in-longhorn-server-terminal-services/
Well, this will prevent 2 admins to make the changes on the same time, i use the console session to install software. Some (3rd) party software is still sensitive to install in a terminal server session instead of a console session. Is it still possible to connect to the console to install software in longhorn?
Using /Console and the 2 terminal sessions, we get a total of 3 interactive sessions that are available to remote desktops in Remote Administration mode. Are we only going to get 2 with Longhorn, or are there going to be a pool of 3 (or more) for remote administration mode in Longhorn?
I would like to echo the same remarks made by Dennis. If there are any apps or operations that need to be performed on the console, will be there be an option to connect to the console via RDP?
You will only get 2 admin connections in 'remote administration mode'.
> You will only get 2 admin connections in 'remote administration mode'.
Not entirely true -- against Win2k3, you can use two remote connections plus also connect remotely with /console, giving total of three possible simultaneous remote admin connections.
This just doesn't make sense. Is this saying that there is no way to log into a console session as an administrator?
Why is that option being taken away? There are MANY instances that I'd need to work "at a server" remotely, and the console is what I need.
This seems like a real step backward - forcing an administrator to physical be at the server to do administrative work.
Thanx for the feedback folks!! Let me try and answer your questions. Please feel free to post any further questions if things are still unclear.
Q: "If there are any apps or operations that need to be performed on the console, will be there be an option to connect to the console via RDP?"
A: In Win2K3, applications used to work only in console session (session 0), because they need to talk to services that ran session 0. With the new architecture, only services run in session 0 and applications run in non-zero sessions. Our app compat component has shims that would help such applications work in non-zero session. So, to run those applications, you do not need to be at console session anymore.
Do you have any specific apps or operations in mind?
Q: "Is this saying that there is no way to log into a console session as an administrator?"
A: Not really. It's saying that you can not connect to session 0 directly - however, the session 0 is not the "console session" anymore.
The console session is just like any other session as far as ability to perform any kind of operations is concerned. The only difference is that the "console session" does not need the protocol handshake between server and client that goes on in case of "remote session".
If you previously logged on to console session (physically at the machine) and now you want to get back to your session remotely, you can do so without using /console switch. However, the "Restrict user to single session" policy plays role for reconnecting to your "console session". Please refer to "Reconnecting to your session on physical console" section in the original post.
What if I'm logged into a machine and TS into it from the console? I do this all the time at work to do things like start builds or scripts in a window I can connect to later.
> What if I'm logged into a machine and TS
> into it from the console? I do this all the
> time at work to do things like start builds
> or scripts in a window I can connect to
You can logon to <Machine-A> locally (at physical console) or remotely, start scripts in a window, then you can log back on to same machine <Machine-A> locally or remotely - you will get back to your session, where you had started the scripts.
Please note that you have to restrict each user to single session (which is set by default) - in case you changed it.
If this does not answer your question, can you please elaborate your scenario by giving machine names as example?
Thanx for your question and feedback!!
Hi All, In Windows Server 2003, the /console option was used for several purposes. With the introduction
With Windows 2003, the console session could see popup error messages from services including Windows. Too many popup messages and your server would hang. A registry change modified this behaviour.
Have the appropriate windows services been re-architected to ensure they no longer pop messages up on the console ? (eg delayed write failure, etc.)
Specific example of needing access to console on Win 2008:
Install Office 2003
Try to run it so you can Activate it
You get 'This feature is not available. For more information contact your system administrator'
Well I am that person... in order for us to activate Office 2003 (for say Presentation Server) we used to have to be in session0... now on 2008 I can not activate Office 2003, making it unavailable to my end users.... Any suggestions?
How about a case where folks are using Virtual Machines and not physical bare-metal hardware? How do we access the console session (session1)?