Windows Service

[AlastairP]

Good afternoon,

I am just trying to understand some design concepts before I continue any further.

I have been working on a control panel program that also starts a com server exe.
The com server performs the heavy lifting.

I need the program to start up when Windows Server starts, so I was going to use Task scheduler to start the program.
However, from what I gather, only programs configured to run as a services will start up when the Windows Server is started/rebooted.
A standard program will require someone to log into one of the accounts before being able to be run.

Therefore I need the com server part of the program to run as a service on startup and the UI can be run on an as needed basis if required.

So the questions are:
Should I revert the com server exe back to a regular exe?
If I start the com server (Or regualar exe) first as a service, how do I communicate with it later from the UI?
At the moment I create an object reference to the com server when it starts and hold that in a _Screen property.

I know I got a lot to do, but a help being steered in the right direction would be greatly appreciated

With regards
Alastair

 

[Olaf Doschke]

I don't know if you need to go this route. Task Scheduler also allows you to run an EXE on the system start without any login, which means within session 0. Your code just can't rely on any network shares mapped as certain drive letters, such mappings and some other stiff are related to an account and its startup, the session 0 account has network access, but through UNC paths. It might not play a role, if you run something server-side, then likely because you actually want it to run at the server that hosts such a file share, which means it's a local drive/partition/folder to it.

It's on page 1 on creating a new task, default the option is to only start with a user-login, but the next option is to not wait for that. Right there, not even buried deep in extended options.

Bye, Olaf.




Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Gagnon]

You should have this option in the task scheduler

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Olaf Doschke]

Just by the way, if you would insist on creating a service, with VFP you are depending on a third-party solution like SrvAny and several articles have been written on how to use that with VFP executables. SrvAny itself runs as the service process. An interactive service is possible, there is one restriction about this, though, the service has to run as LocalSystem.

It's not really worth the hassle to establish that in comparison with activating the option I and Mike Gagnon pointed out, though.

And the only advantage is you can define a recovery behavior of Windows to restart your service when it crashes. But you can also configure a scheduled task to start every minute and only start when it does not run to accomplish the same thing.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[AlastairP]

Good morning,

Thanks for the responses.

The research that I have been doing suggests the following when using task scheduler with Windows Server and Remote Desktop:
- The program will start in Session 0 and the UI is not visible when the user logs in using remote desktop.
- When someone the logs out of the Admin account it may kill the process.

See this:

https://serverfault.com/questions/5...hen-nobody-is-logged-on-and-show-the-window-w

And this:

https://stackoverflow.com/questions/5986598/automatically-run-program-on-windows-server-startup

My idea was to get the IT guy to create a service account just for this application, and use autologon when the server starts, then a lock script as suggested in the first post.
To monitor the application, a tray app will monitor the status of the program from any normal user account when logging in.

However, the answers from the contributors in the above posts suggest that running a windows service is the accepted/specified way of doing this.
I obviously would prefer to use task scheduler as my program as it stands will not require altering.

Alastair

 

[Olaf Doschke]

The serverfault thread does not suggest, that an administrator login kills the running process.
The stackoverflow article also doesn't suggest this, and a log off also won't end processes of Session 0.

So you're misinterpreting this.

Nothing speaks against a scheduled task starting in Session 0, the only problem you have is that logging in (which means logging into any further Session) you don't see anything from Session 0 on the desktop. There is no Session 0 desktop. Marcus, the asker on serverfault states:

when someone finally does log on as Administrator using Remote Desktop Connection the interface (program window) is hidden.

That's his misunderstanding, but he's also no expert. This process is not hidden at that moment, it is always hidden. It runs desktop less in Session 0. And your interpretation of this login killing the process is even worse.

As your program is something that should run unintended then there is no need for a permanent UI at the unintended time anyway. So why don't you split this up? In the simplest case your process could write out a log file and when you log in you can read the progress from this file. That wouldn't even need a part 2 UI EXE, just notepad. You wouldn't even need a login, if this file is written to a share you can get at from your workstation, too. Yes, I said sesion 0 processes can't acces shares, but the server can have a local doirectory that is a file share to workstaions. You're at the root server of the share.

And even if you need more than that, your current UI will display some status, data, whatever. All the forms from that can be put into a secondary EXE that is just the frontend to all this. If you really need to see into an internal status of your unintended Session 0 process, you can communicate with it from your second EXE via data you write into DBFs or text logs as the simplest case. And as you said yourself you're using COM Server, yes, that's also a way to have something you can attach a new process to by GETOBJECT(). It's not only possible for Office automation to make use of that. But that's complicated and also unnecessary, I'd prefer a logfile solution.

I, by the way, did maintain a nightly process that had a UI and was run by task scheduler unintended. It was triggered by time (starting time and within 1 hour on idle system using an account, so not running in session 0), that's not possible at startup, but if you look into my earlier recommendation its actually also just a question of the time-frequency to make this going and have perhaps 5 minutes downtime after server start. Because that would work the same way as with a crashed process, the task scheduler is triggered by time modulo 5 minutes being 0 (so a time HH:MM is HH:M0 or HH:M5) and in the worst case, your process crashed within the last 5 minutes and then is restarted or it never ran in the current server uptime as the server started freshly and is run then. So this one start time and repeat after interval driven solution covers both cases.

I don't know how essential it is your process always runs. In such cases, services are a good idea, but also only if you ever need to interact with them in a way you influence them. The monitoring of progress can always be made with a separate EXE by looking into the created logs or data. A Service is mainly still a service, something offering functionality and accepting communication with it in form of requests, responses being visualized on a client-side connecting to it and making requests to it, the best example is an SQL Server service, that can even be open to requests from the network without a login.

Yes, you can argue that some services you see listed in Windows are nothing you interact with directly. Like the plulg&play service, which in itself also has no UI, only monitors hardware and especially reacts to newly connected hardware with their detection (USB has automated that process of driver installation). You're then only informed, usually. You're rarely asked for a driver setup.

Anyway, in the end, scheduled tasks give you the option I and Mike Gagnon pointed out, which will run always hidden, or you pick the task scheduled by a time in short intervals with the additional condition it's not already running on an account configured including credentials, then you can log into that windows account session and see it. And login as that account or Admin doesn't kill that, too.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[AlastairP]

Hi Olaf,
Thanks for the insight
The UI kickstarts the Com server by reading settings from DBF's.
So yes I could do it another way.
The UI already gets its status updates by way of shared DBF's and text log files so as not to interrupt the com server.
So I could make the UI run on its own and be started and closed independently.


Alastair

 

[Olaf Doschke]

The solution might be an EXE that kickstarts a COM Server instance that runs permanently and a separate UI only gets a reference to it.
I don't know, it might not even make a difference if each UI creates its COM Server at startup. You know much more about what you're actually doing there that needs to run permanently.

We might still be talking cross purposes, I'm thinking of DBFs or log files that contain results, status of what your permanent process does. All the basic core information you want to display in a UI, and maybe also influence what the process does, how it reacts, which jobs it has, etc. So it will be a mix of one-way and two ways communication. he simple end goal is just, that its not necessary to have both in one process and you won't even need interprocess communication, which is complicated, instead you just get information in and out via files.

In any way, this separation can then also make it unimportant, whether you connect to a specific session or start your own, as all sessions see the same filesystem. You share that way, that's just the norm for database applications anyway, nothing new actually, despite the spect of letting something start unattended and start triggered by time/interval/restart.

If your customer still wants a service as a more natural thing that starts with a server, there is no quality difference of a task with defined starttime/interval or the configuration of whether a service starts or not, a service can also be configured to not start, or it can be removed. Just like a scheduled task might be deleted. So what happens is fully under control of an admin anyway.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name