Fog Creek Software
Discussion Board




Windows Terminal Services problem

Hi everyone, I'm hoping someone can help...

We have a project that runs as a service and while running it displays an icon in the system tray.  Everything works fine normally.

However, if we connect to the machine running the service using Windows Terminal Services then we can't see the tray icon.  The service is an interactive service that displays a form when you click on the icon.  Does anyone have any ideas about how to get around this problem?

Thanks in advance!

T.S.
Wednesday, February 05, 2003

A number of things spring to mind, depending on your needs.

If your service needs to open a window on the desktop to respond to a query sent through the network interface (an old geographical information system we had insisted on opening a window on the desktop, even though it was producing maps ment for a web server), you have a flag in the services' configuration: allow interaction with desktop.

If you start the service once and then need to click on a ui element to access its functionality (e.g. MS Messenger), then there's an option in Windows TS that lets you define what happens to the desktop when you disconnect. You could then close the TS client (not 'Log Off', but Alt-F4 the client), and if you reconnect to the client then the desktop session is still there. However, I fear the timeout cannot be set to infinity.
VNC _does_ keep your desktop around forever, maybe you should switch to that, even if it's not as good as TS.

Hope that helps

Yves
Wednesday, February 05, 2003

I agree with the "Interact with Desktop" post from above.  A typical windows service runs under the local system account which does not have access to the desktop, printing, network shares, etc. 
One piece of advice I always hear is to create an account with the privliges you need and run your service under that account.  You could even just run the service under administrator.

Matt Watson
Wednesday, February 05, 2003

Its a well know security warning on windows that allowing services to interact with the desktop makes it possible for the malicious logged in user to elevate to the service's security level.

Basically you cannot completely protect the interaction window from malicious windows messages. 

Exceprt from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure08192002.asp

Services in Microsoft Windows® are generally console applications designed to run unattended with no user interface. However, in some instances, the service may require interaction with the user. Services running in an elevated security context, such as SYSTEM, should not run as interactive services. In the Windows user interface, the desktop is the security boundary, and any application running on the interactive desktop can interact with any window on the interactive desktop, even if that window is invisible. This is true regardless of the security context of the application that creates the window and the security context of the application.

Because of these design features, any service that opens a window on the interactive desktop is exposing itself to applications executed by the logged-on user. If the service attempts to use window messages to control its functionality, then the logged-in user can disrupt that functionality through the use of malicious messages.

B
Wednesday, February 05, 2003

The only account that can run a service in the interactive WinStation is LocalSystem. When the service starts, if it is marked for interaction with the desktop, it starts the service process in WinSta0 instead of the LocalSystem WinStation so that any windows it shows will be shown on the interactive desktop. In the case of Terminal Services it works exactly the same way _but_ the interactive WinStation is that of the local server session. So if you go over to the terminal server and log on locally it should show your icon as you expect but it can never interact with an arbitrary session.

Interacting with the desktop like this is almost always a poor design decision as well as a potential security breach. What you should normally do (and will have to do for TS) is create your service executable and a separate executable that interacts with the user. These two are set up to communicate using one of the many IPC mechanisms. This way any TS session that needs to can run the user interface (as an icon if that's what you want) and you have much greater control over security.

Stephen Martin
Wednesday, February 05, 2003

read the API :) - what I mean is that certain functions behave differently under TS, eg the simple MessageBox() function. The icon may not be visible because it's displayed on another desktop.

na
Wednesday, February 05, 2003

See KB article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q327618

Rob
Wednesday, February 05, 2003

I too have the same requirement of being able to see the icon(of the service that is running) in systray using Terminal Services. How can I make this happen?

Thanks,
Gopi

Gopi Krishna Chebiyyam
Sunday, May 16, 2004

Read http://www.thethin.net/faqs2.cfm?id=397&category=2&sortby=date

Basically, it says to write your service to have NO user interaction. Write a second app that starts automatically whenever any user logs on. The second app has an icon in the system tray and provides all user interaction. When the user changes something, the second app uses named pipes or some other inter-process communication to notify the service.

If you don't have Terminal Services (or XP with Fast User Switching), you can get away with the service handling its own user interaction, although you still shouldn't do it because of security concerns.

Hope this helps.

Chris Ogle
Tuesday, May 25, 2004

*  Recent Topics

*  Fog Creek Home