Re: WTSQuerySessionInformation
- From: "Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx>
- Date: Wed, 11 Apr 2007 19:01:07 +0900
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@xxxxxxxxxxxxxxxxxxxxxxxOK, 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@xxxxxxxxxxxxxxxxxxxxxxxHow 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@xxxxxxxxxxxxxxxxxxxxxxxhttp://msdn2.microsoft.com/en-us/library/aa383838.aspxTo 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: Ivan Brugiolo [MSFT]
- Re: WTSQuerySessionInformation
- References:
- Re: WTSQuerySessionInformation
- From: Ivan Brugiolo [MSFT]
- Re: WTSQuerySessionInformation
- From: Norman Diamond
- Re: WTSQuerySessionInformation
- From: Ivan Brugiolo [MSFT]
- Re: WTSQuerySessionInformation
- Prev by Date: Re: Vista application compatibility modes
- Next by Date: RtlIpv4StringToAddressW entry failure on 2000
- Previous by thread: Re: WTSQuerySessionInformation
- Next by thread: Re: WTSQuerySessionInformation
- Index(es):
Relevant Pages
|
