Is there any way that Microsoft Terminal Services can be used like PC anywhere- that is, to remotely administer a computer at another location?
I know I can get close to this with normal Terminal Services operation, but the problem I'm having is this:
I am running a Windows NT service that automatically restarts a program when the service recognizes that the program has terminated. Unfortunately, the service always starts the program up in the console session, which can't be remotely controlled or monitored through terminal services. Is there any way to remotely control the console session, or to make the service start up a terminal services session first and then launch the program in that context?
> Is there any way that Microsoft Terminal Services can be used like PC > anywhere- that is, to remotely administer a computer at another > location?
Yes.
> Unfortunately, the service always starts the program up in the console > session
Kill the service and start the program manually on the terminal you use. You have a very strange design. If you want some running code to be controllable from many user desktops - then write a service.
> > Is there any way that Microsoft Terminal Services can be used like > PC > > anywhere- that is, to remotely administer a computer at another > > location?
> Yes.
> > Unfortunately, the service always starts the program up in the > console > > session
> Kill the service and start the program manually on the terminal you > use. > You have a very strange design. If you want some running code to be > controllable from many user desktops - then write a service.
> Max > Kill the service and start the program manually on the terminal you > use.
This would defeat the purpose. I want the program to be started up automatically whenever it isn't running, even if no one is logged into the server. This program itself is not a service (and cannot be made into one), but I want it to behave like one. To accomplish this, we wrote a "wrapper" service, which does nothing but start the program when the wrapper finds that the program is not running.
> You have a very strange design. If you want some running code to be > controllable from many user desktops - then write a service.
Perhaps the design is strange, but I can't think of an alternative. As I said, I can't make the program itself into a service. All I want to do is have this program start automatically upon reboot, and then be able to administer the running of the program remotely with Terminal Services if the program runs into problems. This is easy with PC Anywhere. Can I do it with Terminal Services?
> able to administer the running of the program remotely with Terminal > Services if the program runs into problems. This is easy with PC
Sorry, you have added a fake service like SVCANY which will run your app in the service context. OK. Then forget about any chances of seeing its UI - it runs on invisible "service desktop" - TS or no TS.
Write a proper service and control it, say, via COM. Often, things must be done properly - or cannot be done at all.
In NT, service (or SVCANY-like fake) is the only way of running the user-mode process in the absense of the logged on interactive user. In this case, you will not have any access to its UI.
Well, OK, you can cheat NT, switch the desktop and show the visible UI from a service - but it is a bad way, and bad in security terms primarily. Microsoft-supplied services never do this.
> > able to administer the running of the program remotely with Terminal > > Services if the program runs into problems. This is easy with PC
> Sorry, you have added a fake service like SVCANY which will run your > app in the service context. OK. Then forget about any chances of > seeing its UI - it runs on invisible "service desktop" - TS or no TS.
> Write a proper service and control it, say, via COM. Often, things > must be done properly - or cannot be done at all.
> In NT, service (or SVCANY-like fake) is the only way of running the > user-mode process in the absense of the logged on interactive user. In > this case, you will not have any access to its UI.
> Well, OK, you can cheat NT, switch the desktop and show the visible UI > from a service - but it is a bad way, and bad in security terms > primarily. Microsoft-supplied services never do this.
> Max > OK. Then forget about any chances of > seeing its UI - it runs on invisible "service desktop" - TS or no TS.
Well, I do get to see the application's UI in the console session, and I do get to see the application's UI when I use PC Anywhere. I'm not sure what you mean by "invisible service desktop"- the console session is not invisible, and it displays the UI the way I want it to. I just can't see it remotely in a Terminal Services session.
> Well, OK, you can cheat NT, switch the desktop and show the visible UI > from a service - but it is a bad way, and bad in security terms > primarily. Microsoft-supplied services never do this.
How can I do this? I know that it is "bad", and that Microsoft services don't do this, but it might be my only option in the short term. Writing a "proper service and controlling it through COM" isn't something I can do given my current time constraints. Any help you can provide would be appreciated.
On 6 Jan 2003 08:27:20 -0800, sean.do...@acterna.com (seanact) wrote:
>Is there any way to remotely control the console >session, or to make the service start up a terminal services session >first and then launch the program in that context?
Am I missing something? Does not "mstsc /console /v:my-server" do what you want?
