Any reason Session ID = 1 instead of 0 on Vista?

For as long as I can remember, Session ID for a console session has been 0.
We use this value to identify when our software is running from the console,
or running from within a TS or Citrix session. For a variety of reasons, we
need to know.

Anyway, I'm finding that Vista assigns Session ID of 1 to the console
session. Any reason for this, or just for the purposes of ensuring minimal
backward compatibility?

Thanks,

- Joe Geretz -

Joseph Geretz wrote:
> For as long as I can remember, Session ID for a console session has
> been 0. We use this value to identify when our software is running
> from the console, or running from within a TS or Citrix session. For
> a variety of reasons, we need to know.
>
> Anyway, I'm finding that Vista assigns Session ID of 1 to the console
> session. Any reason for this, or just for the purposes of ensuring
> minimal backward compatibility?

It's done for a reason. If you read the old new thing blog at
http://msdn.microsoft.com/oldnewthing you'll see that whatever other
numerous faults we can assign to Microsoft, going around changing important
system parameters just for a giggle to see how many apps they can break in
one day isn't really one of them.

http://www.realvnc.com/pipermail/vnc...er/056565.html might be
of interest to you also.

In message <OP60uZTVHHA.4384@TK2MSFTNGP02.phx.gbl> "Joseph Geretz"
<jgeretz@nospam.com> wrote:

>For as long as I can remember, Session ID for a console session has been 0.
>We use this value to identify when our software is running from the console,
>or running from within a TS or Citrix session. For a variety of reasons, we
>need to know.
>
>Anyway, I'm finding that Vista assigns Session ID of 1 to the console
>session. Any reason for this, or just for the purposes of ensuring minimal
>backward compatibility?

It's part of the process isolation changes in Vista -- Previously, it
was often possible for an app running under Session ID 0 to directly
communicate with services and potentially trick the service into doing
something inappropriate.

Moreover, this change is required for switch user to work.
--
Insert something clever here.

> > Anyway, I'm finding that Vista assigns Session ID of 1 to the console
> > session.

Not quite correct. A console session can be any session other than 0. As for
why the did that...

Short answer: This was done to isolate services from interactive
applications and prevent services from being hacked by end users.

Longer answer:
http://www.microsoft.com/whdc/system.../services.mspx

I don't think identifying console sessions versus terminal server sessions
is really a good plan. With Fast User Switching (which works in a domain in
Vista) any session that is local can actually be a terminal services session.
If you have to do it maybe the better option is to look for the session that
hosts smss.exe or csrss.exe, or one of the other services? I don't know of an
API that lets you identify the origin of a session.


> It's done for a reason. If you read the old new thing blog at
> http://msdn.microsoft.com/oldnewthing you'll see that whatever other
> numerous faults we can assign to Microsoft, going around changing important
> system parameters just for a giggle to see how many apps they can break in
> one day isn't really one of them.

Robert, that link doesn't work.

> I don't think identifying console sessions versus terminal server sessions
> is really a good plan.

We need to identify the workstation that the user is on (i.e. the physical
device with the keyboard and mouse attached). With a workstation (whether or
not fast user switching is in play) it's going to be the workstation the
application is actually running on. With a Terminal Server, it's a different
device altogether, it's the client PC, not the machine which is hosting the
application process. (I'm not at work and so I don't recall offhand the
different function calls for the different scenarios.)

This is the major reason we need to differentiate. On the other hand, if you
know of an API call such as GetUserWorkstation which does this transparently
for us then we wouldn't need to worry about it ourselves explicitly.

Thanks,

- Joseph Geretz -

"Jesper" <Jesper@discussions.microsoft.com> wrote in message
news:995D1649-7646-4595-B63A-634C44A5688F@microsoft.com...
>> > Anyway, I'm finding that Vista assigns Session ID of 1 to the console
>> > session.
>
> Not quite correct. A console session can be any session other than 0. As
> for
> why the did that...
>
> Short answer: This was done to isolate services from interactive
> applications and prevent services from being hacked by end users.
>
> Longer answer:
> http://www.microsoft.com/whdc/system.../services.mspx
>
> I don't think identifying console sessions versus terminal server sessions
> is really a good plan. With Fast User Switching (which works in a domain
> in
> Vista) any session that is local can actually be a terminal services
> session.
> If you have to do it maybe the better option is to look for the session
> that
> hosts smss.exe or csrss.exe, or one of the other services? I don't know of
> an
> API that lets you identify the origin of a session.
>
>
>> It's done for a reason. If you read the old new thing blog at
>> http://msdn.microsoft.com/oldnewthing you'll see that whatever other
>> numerous faults we can assign to Microsoft, going around changing
>> important
>> system parameters just for a giggle to see how many apps they can break
>> in
>> one day isn't really one of them.
>
> Robert, that link doesn't work.

"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:OP60uZTVHHA.4384@TK2MSFTNGP02.phx.gbl...
> For as long as I can remember, Session ID for a console session has been
> 0. We use this value to identify when our software is running from the
> console, or running from within a TS or Citrix session. For a variety of
> reasons, we need to know.

That sounds dangerously like "we need to do it because we've always needed
to do it, and now that we can't do it, rather than revisit whether we really
need to do it, we need to find a different way to do it".

You may have a valid reason, but I just have to ask the question - for
natural curiosity, if nothing else - why do you feel that you need to
differentiate between running your software at the workstation and running
your software via a terminal link?

Alun.
~~~~

> This is the major reason we need to differentiate. On the other hand, if you
> know of an API call such as GetUserWorkstation which does this transparently
> for us then we wouldn't need to worry about it ourselves explicitly.

Sorry, I don't know whether such an API exists. There are APIs for
OpenWindowStation which may help, but that's all I know. I'd suggest trolling
the SDK and see what you find. I'd also be curious to know whether you find
anything.

"Jesper" <Jesper@discussions.microsoft.com> wrote in message
news:41075277-19F2-4F0F-84B9-B4D8F67CF866@microsoft.com...
>> This is the major reason we need to differentiate. On the other hand, if
>> you
>> know of an API call such as GetUserWorkstation which does this
>> transparently
>> for us then we wouldn't need to worry about it ourselves explicitly.
>
> Sorry, I don't know whether such an API exists. There are APIs for
> OpenWindowStation which may help, but that's all I know. I'd suggest
> trolling
> the SDK and see what you find. I'd also be curious to know whether you
> find
> anything.

You could check for the existence of the environment variable "CLIENTNAME",
which will tell you in Citrix and TS sessions what computer was used to
connect in (contrast this with COMPUTERNAME. It generally won't be available
in a session tied to the console - but it might be created, there's nothing
preventing it - a user might say "set clientname=jim" for random reasons.

For TS alone, you could call WTSGetActiveSessionId and compare it to the
result from WTSQuerySessionInformation, as specified in the spec for
WTSQuerySessionInformation. I don't know whether this will work for Citrix
(but I wouldn't be surprised if it does).

Alun.
~~~~

Hi Alun,

> natural curiosity, if nothing else - why do you feel that you need to
> differentiate between running your software at the workstation and running
> your software via a terminal link?

We need to identify the workstation that the user is on. Since this
information is derived differently depending on whether the process is
running on a workstation or within a Terminal Session, we need to know.

Also, we've identified certain features within our code which run
differently on TS than on a workstation. These are few and far between,
however we need to distinguish between these different environments in order
to avoid problems.

BTW, I am able to do this. With a little bit of recoding to account for how
the rules of the game have changed for Vista, I can accommodate both Vista
and pre-Vista conditions.

- Joseph Geretz -

"Alun Jones" <alun@texis.invalid> wrote in message
news:%23HDyhtdVHHA.3332@TK2MSFTNGP04.phx.gbl...
> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
> news:OP60uZTVHHA.4384@TK2MSFTNGP02.phx.gbl...
>> For as long as I can remember, Session ID for a console session has been
>> 0. We use this value to identify when our software is running from the
>> console, or running from within a TS or Citrix session. For a variety of
>> reasons, we need to know.
>
> That sounds dangerously like "we need to do it because we've always needed
> to do it, and now that we can't do it, rather than revisit whether we
> really need to do it, we need to find a different way to do it".
>
> You may have a valid reason, but I just have to ask the question - for
> natural curiosity, if nothing else - why do you feel that you need to
> differentiate between running your software at the workstation and running
> your software via a terminal link?
>
> Alun.
> ~~~~
>