Re: WTSQuerySessionInformation
- From: "Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 11 Apr 2007 09:17:12 -0700
Session zero has stopped being `the console session` starting from Vista.
That's why in Vista the section currently elected to be the console
(and sometimes `incidentally` bound to the glass terminal) shall be
retrieved
with an explicit API call.
I guess I can agree with you that the MSDN documentation is not clear on the
subject.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message
news:ubENYBCfHHA.2376@xxxxxxxxxxxxxxxxxxxxxxx
The ActiveConsole may be in the middle of changing session ownership
Yes we agree that if the console is in the middle of changing ownership
then it's not clear what I should do. My previous posting mentioned that
and you mentioned that. But meanwhile, there's the other 99% where things
are pretty clear and I should try to perform as specified.
How about: there's a particular event and I will notify only users that
can do something about it.
That is not what the spec calls for. The spec calls for notifying the
user who is affected by the event, if the user is logged in at the
console. The spec calls for not notifying the user who is affected by the
event if the user isn't logged in. The spec doesn't mention the
possibility of notifying other users. I think we can presume that a user,
who personally registers for notification of the event, doesn't want some
other user to be notified just because some other user is logged in at the
console when it happens.
Thnk about the headless servers where the console does not really exist.
No kidding. If a user finds a way to register for event notification on a
console that doesn't exist, and the user doesn't log into a console that
doesn't exist, then the user won't get notifications on a console that
doesn't exist. This result seems to be both conformant to the spec and
easy to achieve.
On the MSDN:
I'm not sure what the comment is.
It looks to me standard reference documentation for the API.
Are you serious? Here, maybe you should read these parts of it again:
http://msdn2.microsoft.com/en-us/library/aa383838.aspx
To determine whether your application is running on the physical console,
you can do the following:
As described previously, call WTSQuerySessionInformation and specify
WTS_CURRENT_SESSION for the SessionId parameter and WTSSessionId for the
WTSInfoClass parameter. The session ID returned in ppBuffer is zero for
the Terminal Services console session.
Got it. If the session ID is zero then I'm running on the physical
console.
If the session ID is nonzero then I'm running elsewhere (either serving a
remote user or patiently waiting for a fast switcher to come back).
Applications run in the console session only if the machine administrator
(not just a member of the Administrators group) logs on to the physical
console. Usually, only services can run in session zero, and applications
run in other sessions.
Got it. If the session ID is zero then I'm running on the physical
console
AND the machine administrator is logged in. If the session ID is nonzero
then either I'm running on the physical console and a normal user or other
member of the administrators group is logged in or I'm running elsewhere.
Well, at this point in time I don't care if the machine administrator is
logged in or not, I only care if I'm running on the local console. So if
the session ID is zero (and user is machine administrator) OR the session
ID
is some undocumented magic number (and user is normal or other member of
administrators group) then I'm running on the physical console. If the
session ID is neither zero nor the undocumented magic number then I'm
running elsewhere.
Windows Server 2003 and Windows XP: Session zero might not be attached
to the physical console. This is because session zero can be attached to
a remote session.
Got it. If the session ID is zero then I might be running on the physical
console (and maybe or maybe not the user is the machine administrator,
depending on which preceding rule we believe), or I might be running in a
remote session. If the session ID is an undocumented magic number then
maybe we might figure out if I'm running on the physical console
(depending
on which preceding rule we believe). If the session ID is neither zero
nor
the undocumented magic number then I'm running elsewhere -- no, wait...
the next user to log on uses session one
OK, there's not a simple undocumented magic session ID number which tells
us
if we're running on the physical console, but there's an undocumented
magic
algorithm that can figure it out. Why do I think I'm getting warmer now?
Windows 2000 Server and Windows 2000 Professional: Session zero will be
attached only to the physical console.
Theoretically that's OK. I don't have to care about Windows 2000 for this
particular piece of code... maybe.
Windows Vista:
Um, no. This page doesn't single out Windows Vista. Obviously Windows
Vista has the same rules as Windows XP. That's why there haven't been
tons
of articles telling us how to change tons of code to deal with the
differences between Windows XP and Windows Vista. Well, either that, or
else Windows Vista obviously has the same rules as Windows 2000. Well,
either that, or we're still waiting for specifications to be decided for
Windows Vista.
"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:uEnZFpAfHHA.4552@xxxxxxxxxxxxxxxxxxxxxxx
The ActiveConsole may be in the middle of changing session ownership
(for example, a FUS switch, or other TS-in/TS-out scenarios.
Depending on how reliable/resilient your code needs to be,
there might be some complicated schema that monitors session change
events
from the session control manager.
On the design:
`There's a particular event that is relevant only at the console`.
How about: there's a particular event and I will notify only users that
can do something about it.
Thnk about the headless servers where the console does not really exist.
On the MSDN:
I'm not sure what the comment is.
It looks to me standard reference documentation for the API.
"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message
news:%23DrPWa9eHHA.4128@xxxxxxxxxxxxxxxxxxxxxxx
OK, I've called WTSGetActiveConsoleSessionId in several situations
including this one, and I'll try to find what API gets the current
session ID. Actually this makes me figure out that there might not be a
solution, because the physical console might be in the middle of
changing ownership at the time.
The reason for finding out whether I'm running on the physical console
or not, in this case, is one particular situation that came up
yesterday. When detecting one kind of event that's being monitored, if
the affected user is logged in at the console then I should call
WTSSendMessage, but if the affected user isn't logged in at the console
then I should do nothing.
Meanwhile, what do you think about that MSDN page?
http://msdn2.microsoft.com/en-us/library/aa383838.aspx
"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:eE%23T$t5eHHA.4020@xxxxxxxxxxxxxxxxxxxxxxx
How about WTSGetActiveConsoleSessionId ?
You compare the current session ID with e active console ID,
and, you should be done.
Why needing to know that is relevant is maybe the next good questions
--
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of any included script samples are subject to the terms specified
at
http://www.microsoft.com/info/cpyright.htm
"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message
news:%23tH1n4yeHHA.4128@xxxxxxxxxxxxxxxxxxxxxxx
http://msdn2.microsoft.com/en-us/library/aa383838.aspx
To determine whether your application is running on the physical
console,
you can do the following:
As described previously, call WTSQuerySessionInformation and specify
WTS_CURRENT_SESSION for the SessionId parameter and WTSSessionId for
the
WTSInfoClass parameter. The session ID returned in ppBuffer is zero
for
the Terminal Services console session.
Got it. If the session ID is zero then I'm running on the physical
console. If the session ID is nonzero then I'm running elsewhere
(either serving a remote user or patiently waiting for a fast switcher
to come back).
Applications run in the console session only if the machine
administrator (not just a member of the Administrators group) logs on
to the physical console. Usually, only services can run in session
zero, and applications run in other sessions.
Got it. If the session ID is zero then I'm running on the physical
console AND the machine administrator is logged in. If the session ID
is nonzero then either I'm running on the physical console and a
normal user or other member of the administrators group is logged in
or I'm running elsewhere. Well, at this point in time I don't care if
the machine administrator is logged in or not, I only care if I'm
running on the local console. So if the session ID is zero (and user
is machine administrator) OR the session ID is some undocumented magic
number (and user is normal or other member of administrators group)
then I'm running on the physical console. If the session ID is
neither zero nor the undocumented magic number then I'm running
elsewhere.
Windows Server 2003 and Windows XP: Session zero might not be
attached to the physical console. This is because session zero can be
attached to a remote session.
Got it. If the session ID is zero then I might be running on the
physical console (and maybe or maybe not the user is the machine
administrator, depending on which preceding rule we believe), or I
might be running in a remote session. If the session ID is an
undocumented magic number then maybe we might figure out if I'm
running on the physical console (depending on which preceding rule we
believe). If the session ID is neither zero nor the undocumented magic
number then I'm running elsewhere -- no, wait...
the next user to log on uses session one
OK, there's not a simple undocumented magic session ID number which
tells us if we're running on the physical console, but there's an
undocumented magic algorithm that can figure it out. Why do I think
I'm getting warmer now?
Windows 2000 Server and Windows 2000 Professional: Session zero will
be attached only to the physical console.
Theoretically that's OK. I don't have to care about Windows 2000 for
this particular piece of code... maybe.
Windows Vista:
Um, no. This page doesn't single out Windows Vista. Obviously
Windows Vista has the same rules as Windows XP. That's why there
haven't been tons of articles telling us how to change tons of code to
deal with the differences between Windows XP and Windows Vista. Well,
either that, or else Windows Vista obviously has the same rules as
Windows 2000. Well, either that, or we're still waiting for
specifications to be decided for Windows Vista.
Meanwhile, back at the unfunny farm:
How can I figure out if I'm running on the physical console? (In
Vista.)
.
- Follow-Ups:
- Re: WTSQuerySessionInformation
- From: Norman Diamond
- Re: WTSQuerySessionInformation
- References:
- Re: WTSQuerySessionInformation
- From: Ivan Brugiolo [MSFT]
- Re: WTSQuerySessionInformation
- From: Norman Diamond
- Re: WTSQuerySessionInformation
- From: Ivan Brugiolo [MSFT]
- Re: WTSQuerySessionInformation
- From: Norman Diamond
- Re: WTSQuerySessionInformation
- Prev by Date: Re: Track down name of parent process
- Next by Date: Re: tips for getting started writing a file system minifilter
- Previous by thread: Re: WTSQuerySessionInformation
- Next by thread: Re: WTSQuerySessionInformation
- Index(es):
Relevant Pages
|
