WTSQuerySessionInformation function
Applies to: desktop apps only
Retrieves session information for the specified session on the specified Remote Desktop Session Host (RD Session Host) server. It can be used to query session information on local and remote RD Session Host servers.
Syntax
BOOL WTSQuerySessionInformation( __in HANDLE hServer, __in DWORD SessionId, __in WTS_INFO_CLASS WTSInfoClass, __out LPTSTR *ppBuffer, __out DWORD *pBytesReturned );
Parameters
- hServer [in]
-
A handle to an RD Session Host server. Specify a handle opened by the WTSOpenServer function, or specify WTS_CURRENT_SERVER_HANDLE to indicate the RD Session Host server on which your application is running.
- SessionId [in]
-
A Remote Desktop Services session identifier. To indicate the session in which the calling application is running (or the current session) specify WTS_CURRENT_SESSION. Only specify WTS_CURRENT_SESSION when obtaining session information on the local server. If WTS_CURRENT_SESSION is specified when querying session information on a remote server, the returned session information will be inconsistent. Do not use the returned data.
You can use the WTSEnumerateSessions function to retrieve the identifiers of all sessions on a specified RD Session Host server.
To query information for another user's session, you must have Query Information permission. For more information, see Remote Desktop Services Permissions. To modify permissions on a session, use the Remote Desktop Services Configuration administrative tool.
- WTSInfoClass [in]
-
A value of the WTS_INFO_CLASS enumeration that indicates the type of session information to retrieve in a call to the WTSQuerySessionInformation function.
- ppBuffer [out]
-
A pointer to a variable that receives a pointer to the requested information. The format and contents of the data depend on the information class specified in the WTSInfoClass parameter. To free the returned buffer, call the WTSFreeMemory function.
- pBytesReturned [out]
-
A pointer to a variable that receives the size, in bytes, of the data returned in ppBuffer.
Return value
If the function succeeds, the return value is a nonzero value.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Remarks
To retrieve the session ID for the current session when Remote Desktop Services is running, call WTSQuerySessionInformation and specify WTS_CURRENT_SESSION for the SessionId parameter and WTSSessionId for the WTSInfoClass parameter. The session ID will be returned in the ppBuffer parameter. If Remote Desktop Services is not running, calls to WTSQuerySessionInformation fail. In this situation, you can retrieve the current session ID by calling the ProcessIdToSessionId function.
To determine whether your application is running on the physical console, you must specify WTS_CURRENT_SESSION for the SessionId parameter, and WTSClientProtocolType as the WTSInfoClass parameter. If ppBuffer is "0", the session is attached to the physical console.
Requirements
|
Minimum supported client | Windows 2000 Professional |
|---|---|
|
Minimum supported server | Windows 2000 Server |
|
Header |
|
|
Library |
|
|
DLL |
|
|
Unicode and ANSI names | WTSQuerySessionInformationW (Unicode) and WTSQuerySessionInformationA (ANSI) |
See also
- WTS_INFO_CLASS
- WTS_CLIENT_ADDRESS
- WTS_CLIENT_DISPLAY
- WTS_CONNECTSTATE_CLASS
- WTS_SESSION_ADDRESS
- WTSCONFIGINFO
- WTSINFOEX
Send comments about this topic to Microsoft
Build date: 3/7/2012
So, if GetSystemMetrics(SM_REMOTESESSION) returns 0, everything is OK. But when it returns 1 (or != 0) I have to do an additional check since it might be an inactive user (logged-in but not the current user) in a FUS situation etc.
In such cases I would query SESSIONNAME environment variable and if it is "Console" I know that it is a console and if not "I have to assume" it is remote?
Is this correct?
-- hfrmobile
WTSQuerySessionInformation(WTSClientProtocolType) **ppBuffer = 2 = WTS_PROTOCOL_TYPE_RDP when the
current session is connected to via remote desktop and 0 = WTS_PROTOCOL_TYPE_CONSOLE when not.
WTSQuerySessionInformation(WTSConnectState) **ppBuffer = 0 = WTSActive when the session is active either
at the console or via remote desktop, 4 = WTSDisconnected when the session is not active.
When WTSGetActiveConsoleSessionId() == the value you get back from ProcessIdToSessionId(GetCurrentProcessId()) then the session is being used at the console (local computer) and is active.
GetSystemMetrics(SM_REMOTESESSION) == 1 indicates either the current session is connected to via a remote desktop client OR the current session is not active (a remote desktop connection may or may not be present on a FUS enabled machine). GetSystemMetrics(SM_REMOTESESSION) == 0 indicates the current session is the active console session (ie locally logged in to the machine). Bottom line, don't rely the non-zero value indicating a remote desktop connection unless you know code will only run when you are the active session (eg WM_PAINT handler, keyboard or mouse event handlers).
Note that on Vista, unlike XP, FUS (Fast User Switching) is enabled for domain joined computers and so you can have more than one user logged in at the same time just like you could in XP non-domain joined computers.
bool fActiveSession = false;
DWORD dwSessionID = -1; // 0 is 1st console session created on XP, 1 is 1st console session on Vista
LPTSTR pData = NULL;
DWORD cbReturned = 0;
ProcessIdToSessionId(GetCurrentProcessId(), &dwSessionID);
if( WTSQuerySessionInformation(WTS_CURRENT_SERVER_HANDLE, dwSessionID, WTSConnectState, &pData, &cbReturned)
&& (cbReturned == sizeof(INT)) )
{
// if we get WTSActive we're in the active session, otherwise we assume we're not in the active session (WTSDisconnected)
fActiveSession = (*((INT *)pData) == WTSActive) ? true : false;
}
WTSFreeMemory(pData);
// fActiveSession indicates if we are the active session (true) or not (false)
// Note on a terminal services server, there can be more than one active session
// on most machines (ie desktops) there can be only one active session
- 5/2/2007
- William Sproule - MSFT
- 5/2/2007
- William Sproule - MSFT