I have a process which can be run either as a Service (Local System account) or as a regular process (started by a logged-in user). This process runs other processes, some of which open user-response windows. With me so far?
So, if I’m on the console (the keyboard & screen are directly attached to the physical machine) I can see these windows and click in them and etc.
If I log on to the machine using Terminal Services, I don’t see these windows and I can’t respond to the prompts, click the buttons, etc. This is true even if the Windows box in question is a Win2K3 machine and I’m using the TS /console option.
Let’s say the process I’m running is WordPad, just as an example. I want to be able to type in the WordPad window and then save and close. How can I force that to happen from my Service?
I think the simple answer is you can’t. WindowsNT was designed with a single console and user in mind. Citrix added the whole multi-user/multi-console functionality, only to have MS scarf it for Terminal Services. But the integration is still not quite deep enough. So there are multiple virtual consoles (used for terminal services), and a single physical console (an actual display) and a single virtual physical console (mstsc /console) to pretend that you are physically logged into the box when you are not.
If you are at the box, your logged in user and your service share the only physical console - so your service launched interfaces are visible. If you are logged in via Terminal Services, your user processes are connected to a virtual console (even when using /console) , but your service will still assume that it can use the physical console. So the display goes there. I get this occasionally with Zone Alarm and Fast User switching. A net application fails to launch. Sometime later I switch user, and they have the Zone Alarm popup that blocked my application.
You can identify the virtual consoles, but I don’t think that you can change the console, or even determine who actually owns the console. I have tried to do this in the past, and got very frustrated and gave up. This was a few years ago, though. There may be better ways to achieve what you want to do, using privilege escalation or a client/service interface.
There is a service configuration setting “allow interaction with console”. ensure that is enabled.
I suspect that si_blakely has it nailed.
The original NT service infrastructure was designed to NOT have UI, period, amen. When MSFT bolted on the [allow console interaction] feature in Win2K, they may have not gone too deep into the corner cases. I think the issue is much more in the service architecture than in Terminal Services itself.
If you guys wrote the service software or the UI software, you have an opportunity to dig into the code and some serious Windows API stuff to ensure you’re interacting with the right “console”. The usual UI-writer’s naive assumption about physical and logical consoles being equivalent is not true in this case.
I’ve worked around a similar problem. I’d suggest a combination of the advice about and what you are already doing.
If you set the service to “Interact with desktop” it should be running in the base window station (WinSta0 iirc). If you then RDP in using the /console option, you should both hit WinSta0.
If this doesn’t work post a response - I’ve got a very good Windows Internals book (the Russanovich) which documents parts of this. I’ll look it up for clarity.
Your other option (which may not be feasible) is to have the app authors make some changes to make this more TS friendly.
tim
ps I did think of another option - do you actually need user interaction? If not can’t use just use COM to instance Wordpad (or whatever with a COM interface) and push the data? Alternatively, what about pushing events to the window handler for the app you want to mangle. I think this is just about OS legal.
“Interact with the desktop” is set on the service. I’m guessing that’s what LSLGuy means as well. The [allow console interaction] feature of TS is, I believe, only supported when connecting to Win2003.
Even with “Interact with the desktop” and mstsc /console, with the Service running on Win2k3, I don’t see the process. I do see other console messages, so I’m pretty sure the /console option is working, just not the way I need.
I do have access to the development group for the service, but the likelihood of getting a “fix” for a problem that is really just a customer request is pretty darned small. Fixing the client’s application (which, of course, is not WordPad) so that it doesn’t require interaction is even less likely.
I’m just the humble consultant trying to keep the customer satisfied, satisfi-i-ied.
So, the question is, can I force a process to run against WinSta0? I know I can use & to force a process to run in the background, what I need is the inverse.