Re: WTSQuerySessionInformation
- From: "Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 11 Apr 2007 00:23:39 -0700
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
- Prev by Date: Re: WTSQuerySessionInformation
- Next by Date: Re: Vista application compatibility modes
- Previous by thread: Re: WTSQuerySessionInformation
- Next by thread: Re: WTSQuerySessionInformation
- Index(es):
Relevant Pages
|
Loading
