Otdfbt

I'm running a desktop application as a service with the help of NSSM (Non Sucking Service Manager), which is a wrapper for applications which aren't made to run as a service to be run as a service.

I use an old laptop with Windows 10 as a server by running a few applications as Windows services. On the laptop there isn't any user logged in, so that it requires less resources and thanks to the Windows services the applications are always running also when Windows installs new updates and reboots.

Now I would prefer if the applications could run as Windows services by themselves without the help of another application (NSSM), but I know that it will never happen. The applications are desktop applications and never meant to run as a service; the developers will never enhance them with such feature. (I have already asked it.)

Actually there is an alternative to running an application as a service and it would be starting the application with Task Scheduler with the "on Windows startup" trigger.

In both cases the user doesn't have to be logged in and the computer can reboot automatically and the application should be always available in the network. The advantage of the Task Scheduler would be that the application doesn't require any wrapper (NSSM).

But I'm not quite sure about the reliability of the Task Scheduler. A Windows service in meant to run an application 24/7 and it has many recovery options. Task Scheduler is meant to run an application periodically and not 24/7; therefore there isn't any recovery option.

So my question is:

Is the Task Scheduler with the "on windows startup" trigger a valid alternative to a Windows Service or not?

Has somebody experience with both methods and can explain better the advantages and disadvantages of both?

Yes, in your use case it is, however my understanding is that generally the task scheduler expects the task to end at some point (and in fact has a default option to force the task to end if it doesn't end by itself) and you may be testing some unknown arbitrary or at least unforeseen limits by running it this way. If you do use a scheduled task it might be a better approach to have a separate scheduled task to start the application and another to stop (and/or restart) the application. You can schedule the starting task to run on windows startup and run the other task(s) through remote management.

One area where it's not equivalent is service dependencies. There's no built-in way to make a scheduled task depend on another to run, whereas you can with services. Another area would be event logging. I would suspect that neither of these would be useful in your use case because many applications keep their own logs if necessary and do not depend on other applications to run.

Both have options for recovery/restart after failure

and both can be configured for delayed start after startup.

I could leave you a comment, because Google sometimes is useful, but I remember that long time ago I wanted to achieve the same thing.
In that case, I used a resource kit for Windows Server 2003.
It was containing a tool to create a service. Unfortunately, I don't find information about what I was using at that time*.

Still, a Google search shows many results:

1) Using sc.exe
https://support.microsoft.com/en-us/help/251192/how-to-create-a-windows-service-by-using-sc-exe

https://stackoverflow.com/questions/3663331/when-creating-a-service-with-sc-exe-how-to-pass-in-context-parameters

Here is an example:

C:Documents and SettingsAdministrator> sc create asperacentral
binPath= "C:Program FilesAsperaEnterprise ServerbinDebugasperacentral.exe"
DisplayName= "Aspera Central"
start= auto

2) Using *svrany:
This was the tool I was using, just remembered. But it is quite old now and I'd not suggest you to use it, even tho I guess it still work (with Windows 7 it does).

3) Using srvstart.exe:
https://www.rozanski.org.uk/software

A tool that I heard not long ago, never used.

I am sure there are many and many others, but I would give a try to sc.exe of method 1.