>Services are just EXEs just like scheduled tasks and Scheduled tasks can in fact run in the same execution context as services (when you configure a task you specify account and launch options just like a service).
>
>If a service crashes it doesn't auto-restart any more than a scheduled startup task. Crash and you're hosed. In the end both service and scheduled task target are EXEs with a front end interface that launches them. The EXE is the key, the rest is just a launcher.
>
>The only difference is perceived: Server admins tend to be more familiar with Service installation and automation as opposed to scheduled tasks. You can start and stop serviecs through the service interface, although you can do the same with an EXE that has a proper interface to do the same.
>
>OTOH, it's easy enough to create services in .NET that it's not a big deal. Unfortunately Microsoft (as usual) didn't provide all the tools to build solid services (namely the service control interface to manage registration/uninstallation/start/stop etc.). There are libs out there that help with that.

Thank you

So, given the fact that there won't be any login allowed anymore on all the Web servers and I have a conflict managing entries in the Scheduled tasks now because the EXE is on a share located on another computer, which gives a class not registered non related message, do you see as going with a Service the way to go? And, you're right. This is what we are pretty much imposed to do because the new environment is pretty much as secure as NASA so I lost a lot of control over managing those robots.

To make it simple, as soon as I copied the entire Web site into a local drive, everything starts to work as before with no security boundaries. But, now that the Web site is on a share located on another computer, we have to use domain accounts and this no longer works.