I haven't had time to write a script that uses the .dll but I think there a script somewhere in the forum... Yes -> http://www.kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=2;t=003385#000010

The way I tested the .dll calls was using a small util TSQuery from Clusteresis, they have a couple of freeware utils for WTS (http://www.clusteresis.com/itm00006.htm). The problem is that the results returned didn't excactly contain the info I hoped for. If you look at MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/e n-us/termserv/termserv/wtsquerysessioninformation.asp) I kinda hoped that "WTSClientProductId" or "WTSClientBuildNumber" could be used to retrieve OS of the client, but the build is the TS client build (and since you can install a W2K TS client on a Win95 this won't do any good) and I don't know what to do with the ProductID returned, as I recall it returned 1 or 0 no matter what client OS I connected from [Frown]

I wrote Clusteresis and asked them about the problem and here's what I got from them:

---
The TSQuery command uses the Terminal Services API and in some cases this
API does not return the correct values apart from on systems with Citrix.
There is no easy way to get the OS of the client - you can get the IP, do a
reverse lookup using DNS (or nbtstat -A for the Netbios name) machine name
and then query Active Directory using ADSI (if you are using it) for the OS.
This attribute is filled in by Windows 2000 clients and above. Windows NT 4
clients will exist in the directory (i.e they have a machine account) but
don't fill in this attribute. Windows 9x clients won't be in the directory
at all.

All in all it's not easy however.

Hope this helps,
Support@Clusteresis.com
---

It seems that the TS API is rather unreliable so I've pretty much given up on finding the OS info through TS API calls...

I'm now trying to figure out a way to lookup the OS using the clients IP address (because this info can be retrieved for the TS user using the TS API calls!)... As we discussed a lookup in the registry wont work because of missing admin privs. RPC calls or a port scan may work... How network and post scanners (like NSS from www.gfi.com) finds the OS on a remote system I don't know, but it would be REALLY nice to know (I wrote them monday but haven't gotten an answer yet).

I'm thinking of logging a case with Microsoft Support - if anything comes out of this I will post it here!

If anyone else have other good suggestions, please post them [Smile]

/Nicolaj

[ 20. November 2002, 09:51: Message edited by: nra ]