//TODONT: Use a Windows Service just to run a scheduled process

A common requirement in business application is a scheduled process - call a webservice, process the data, and FTP the results to a business partner, for instance. Developers kick around possible solutions - BizTalk's overkill, DTS won't handle it well, what to do?

Invariably, someone suggests a Windows Service with a timer. Just as invariably, when you try to talk them out of it, they'll condescendingly tell you that Windows Services are easy to write in .NET. "Trust me, it's not hard - we'll write a simple service with a timer which will do a simple time check..."

A Windows Service is the wrong solution to scheduling one-off custom processes. The right solution for scheduling simple processes is the Windows Task Scheduler.

Let's look at what Windows Services are designed for. From the Windows Help documentation:

A program, routine, or process that performs a specific system function to support other programs, particularly at a low (close to the hardware) level. When services are provided over a network, they can be published in Active Directory, facilitating service-centric administration and usage. Some examples of services are the Security Accounts Manager service, File Replication service, and Routing and Remote Access service.

Web servers qualify as services, databases qualify as services, and the above Windows system features qualify as services. The Task Scheduler qualifies as a service. Possibly, custom server applications may qualify as a service if it needs to run round the clock and is written with the greatest sobriety, responsibility, and respect. Your scheduled file FTP doesn't qualify as a service.

A Windows Service which runs a timer needs to run Automatically, which means it will start up before you can log onto the machine and churn away until the machine is shut down. If they hang or have a slow memory leak, they'll continue to be a drag on the system until the service is restarted (or they crash the machine). I can't tell how many times I've heard the following in production meetings: "The cause of the outage was the WhamoInhouse Service. The resolution was to restart the service." Or, worse, application servers need to be restarted regularly because they're hosting poorly written services, but the IT shop blames the operating system.

Windows Services do offer sophisticated Recovery actions (on first, second, and subsequent failures you can specify that a program to be executed, or that the service or computer be restarted), but they're geared towards hard failures of the executable rather than business process failures, and they don't respond to things like memory leaks or hanging network connections. They offer absolutely no scheduling, because services are designed to run all the time. On the other hand, Windows Scheduled Tasks have advanced scheduling features which can be accessed administratively. If the business requirements for my scheduled FTP task change two years down the road so the FTP should happen twice a day every Monday, Wednesday, and Friday, the change can be made by an administrator. The task schedule has been tested across leap years, daylight savings time, and clock changes; most custom timer routines I've seen haven't.

Scheduled console applications are easier to design, build, test, deploy, and install - especially compared to a professional service which can run reliably for weeks end. This wouldn't by itself be a compelling argument if a Windows Service were the right solution by other criteria, but since it's not, this is another nail in the coffin. Consider, then, that your extra time spent building a service is wasted development time. Maybe fun "I am a bigtime coder now" development time, but not of any business value.

Scheduled console applications are easier to run in an ad hoc manner when necessary. Let's say the webservice vendor calls three hours after our process ran to inform us that he had a data corruption problem which has been corrected and we should re-run our process. In the case of a Windows Service with a timer, we'd be scratching our heads; with our console application we can run it manually whenever we want.

Finally, running separate Windows Services with their own timers is just plain inefficient with server resources. Ignore for the second the fact that we're hogging CPU and memory space 24/7 for a process that runs occasionally; multiple independant timers which check the time every few seconds is dumb.

If I kept writing Windows Services with timers, eventually I'd start to think about writing a single host system with a timer. Then I'd want to add in some more advanced scheduling features; perhaps even some logging. Eventually, I'd have a Windows Service that handles scheduling of child processes, and if I devoted years to enhancements and testing, I'd eventually arrive at... the Windows Task Scheduler.

If you're writing a Windows Service that runs a timer, you should re-evaluate your solution.


  • Great comment!

    I made the same mistake of building an app with a timer, but in practice, the Win Task scheduler is turning out to be a much better use of resources for the process I'm doing.

  • It's perfectly possible to write a windows service which installs, uninstalls, runs as a service, and runs in console mode all from the same executable. So this takes care of the head scratching.

    Windows Services are great for always on, no desktop interaction, dependency on other services, recovery in case of hard failures, remote management via various APIs.

  • Brian -

    I'll agree - if you need your process to run more often than once a minute, a Service probably makes sense. At that point, your program is running pretty much continually, which I see as a Service.

    I don't see your second point, though. There's no reason a console app kicked off by the Task Scheduler can't have an internal timer. The point is that Services offer zero support for scheduling, whereas the Scheduler offers at least a framework. Again, if you're talking seconds then you're not really talking about a scheduled process any more.

  • Yves -

    I don't see how that solves anything. We still need to decide how to deploy the application, and what we use to schedule it. Should I build a multifunctioned app with a timer, internal scheduling, and support for service install just in case, then deploy it as a console app under the Scheduler? (scratches head)

    The point is that we need to pick a system architecture. I agree with all the good things you mentioned about Services and would gladly use a Service for always on systems, but they don't make sense for occasional scheduled tasks.

  • Jon -

    Why do I feel like this was directed at me? :)

    Of course, I agree with you - Windows Services ARE significantly overkill for timed apps. The Task Scheduler is a much better solution - however, there are some very good reasons for using a service.

    Services can be easily monitored using something like MOM to instantly alert admins if the service stops or hangs. If someone comes in and cancels or pauses your scheduled service, you won't know it right away. You MIGHT know it if you routinely monitor the OUTPUT of the app, and you see that it didn't run at it's required time.

    That might be fine for a lot of scheduled processes... but if the process absolutely, positively has to run at a certain time, and we need to actively monitor it to ensure that it can, then writing a Windows Service might be a valid choice. At least until the Task Scheduler has the ability to monitor the status of every scheduled task, and escalate issues.

  • Bill -

    I don't know how many times I've had this discussion, and your name definitely wasn't on my mind when I wrote this.

    Part of the reason I posted this was to hear some good counterpoints. Thanks for yours - that definitely makes a lot of sense.

  • I have a Lotus Notes Agent (Java Agent to be specific) calling a .Net URL, which in turn do file download and processing.
    Since I use time tested schedule functionality of Lotus Notes to trigger a URL, I do not have to worry about scheduling at .net side..

    But I wonder whether this has any bad side effects..

  • I agree with you 100% on this one. If you need a Windows service, you'll know it, and it will be something much more involved than simply timing a job.

    Console applications are much easier to write, and also *much* easier to debug than a Windows service.

    The main reason I would default to a Windows service is if I needed to trap events, keep watch on something, or listen for incoming connections, but even for those there are solutions that I would pick over a Windows service. Especially in a SOA, scheduling console apps to interact with your services becomes very common, and a very elegant and simple design.

  • I have schedule a task to run in win2000 every 1 minutes but i need to reduce the time every 30 seconds.

    help required.

  • There are also some third party solutions to run apps AS services, firedaemon being one of them. You get the best of both worlds then.

  • I like the "Task Scheduler" in Vista and Windows Server 2008: it's easy to schedule something to run every 5 minutes indefinitely or do just anything I need.

    I'm a long term Unix user, and I always felt that cron was a lot better than the "Task Scheduler" in Windows XP. These days I'd like to see a GUI for cron that's half as good as Vista's Task Scheduler.

  • I see a couple of issues with your blanket assumptions and solution. Whih a console app run as a schedulked task, that app has to run under the account of a role or individual. Then you have issues with passwords...

    If you have an unhandled exception, the app hangs until someone pcanywheres to the box clears out the error. On a ntservice it will be cleared, logged and restarted. I do nto have to actually pcanywhere to do administrative tasks. I just attach service manager to the servers in question. Say you have written an application to post data to a webservice or save off data from your webserver to a different server and you want it to run every 5 minutes, and you have numerous servers for this to run on. You are MUCH better off writing an NT service to mange the transactions just for the reasons above. If you have 10k a day hitting each server, the console app from a scheduled task is a nightmare from a maintenance perspective. In my company of over 3k in IT, we have both running, we get that type of traffic, and our plan is to replace EVERY schedule task that is doing 'service' type work.
    In my experience people who create a scheduled task and console app are the same people trying to get excel installed on the webservers too.
    If I had it running once a day fine, your solution woudl be fine. You will still have issues with DR watson, errors, potential security problems(It is much easier to change the code of a console executable on a managed server than it is a NT service) If I uninstall and reinstall a service that will show up in the logs. Replace an exceutable, no one many notice.

    If your approach is the best way, why are anti-virus software managed as services? Why isn't indexing just a scheduled task that goes off every few minutes.

  • Nice article. I almost went down the path of writing a windows service to run a couple of jobs...one once a month and another once a week. Service approach definitely overkill and I think I'll go for a couple of simple console apps and the windows task scheduler now.

  • but the problem of using console application and scheduler are: 1st, we need to login the system. 2nd, the console application might popup the DOS window.

  • Jon,

    How do I configure the task scheduler for my application as a part of my setup/install program?

  • Let me start be saying I'm all for easy, but the bottom line is Windows Schedule Tasks is poorly written code. I have three dramtically different environments all running the same little .exe, none of them are stable or reliable. Oh it will tell you it has run with no problems, and it's lying through it's teeth. I've tried launching to from a batch file - no good. I've tried 3600 different combinations of timers, multiple jobs, so on and such forth. It will run for a couple of hours or days, then fail. It has been the most frustrating thing I've dealt with in recent history.

    So let me reiterate, if you rely on the task to run - DO NOT USE the task scheduler.

    Thanks for letting me vent...

  • A bit late to the dance, but thanks for your insight. I developed two console apps to run as scheduled tasks and a co-worker of mine recommended a Windows Service. Since console app and Services are not my domain, I second guessed my scheduled task solution; however, I wasn't positive that the scheduled task solution was in-fact a better solution, so I did a search and for you. Many thanks. Now I can take the next week off... Yeah right! Peace... -Dan

  • Sorry,got it wrong. Don't have VB on my laptop and read source in notepad.

  • Just this morning, Task Scheduler failed me again. The only think I saw was "Missed" in the status column. BTW, it is now 2008 and no improvment on this front.

  • The reason everyone goes with a service instead of a scheduled task is because they don't want a console window flying up every so many minutes on the server. You see, Microsoft's implementation of scheduled tasks is pathetic compared to Linux or Unix, which can background those processes.

  • As a sysadmin I agree, there are far too many 3rd party apps which think their product is the greatest thing ever and needs it's own service. Fighting the good fight :)

    My problem with Task Scheduler is that if you change the Administrator password (I deal with a lot of SBS boxes) then you have to either remember to change the scheduled tasks, or have them all fail quietly.

    I wish Task Scheduler picked up the new password, I have already authorised it to run already, and arn't changing anything.

  • totally agree..

    i worked at a place that did just this for a LOT of things. they would write a windows services that would run at specifed intervals so it could "execute" a web service to run a job.

    i did try to explain the fallacy of it but they didnt want to change their "architecture".

  • My company does everything with services now. We found them to be far more reliable than scheduled tasks and they let us do other nifty things like actually monitor them.

    Scheduled tasks are fine for ad-hock timing or a weekly updater program, but not for mission critical applications.

  • > A Windows Service which runs a timer needs to run Automatically, which means it will start up before you can log onto the machine and churn away until the machine is shut down.

    Good. The machines I use for services are for the services, users shouldn't be logging on.

    > If they hang or have a slow memory leak, they'll continue to be a drag on the system until the service is restarted (or they crash the machine).

    Monitor and fix.

    I want to know when my 30 sec task starts taking 10 minutes, and I want to know immediately. Services give me that, scheduled tasks don't.

    > Or, worse, application servers need to be restarted regularly because they're hosting poorly written services, but the IT shop blames the operating system.

    Then fix the services. Bad code is bad code no matter how it is launched.

  • Why not just use Chron?

  • Security templates applied to military computers will often disable the Windows Task Scheduler. The service can be re-enabled after applying the template, but a new template will again disable the service.

    Perhaps I can write a service that periodically makes sure the Task Scheduler is not disabled....

  • I've created web services that are invoked by VBScripts running according to a schedule set up in Windows Task Scheduler. I don't like asking the web hosting company to set up scheduled tasks or to update my scripts but this does have the advantage in that I can update the web service and invoke it manually any time I want.

  • you can use windows 'AT' but it doesn't do seconds so every task has to wait 1 minute. If you are running an interactive service that writes out a script- such is the case I've used it- you have to wait 1 minute and caluculate the time now plus 1 min for the time to schedule the task. Annoying but somewhat reliable and doesn't have the complexity of windows services or the foregroundedness of task scheduler.

  • In the past, when I've wanted a task to execute every 30 seconds, I simply created two tasks that each run once per minute, but have a *start Time* 30 seconds offset from each other.

  • If you're using the Windows Task Scheduler to schedule a program which might take longer to run than the period and you want to avoid running two instances of the same program (for example you schedule a process to run every 5 minutes but it might take 10 minutes to run.) Then you can create a Mutex and check that in your program. A recent program I've just written checks the Mutex on startup and if another instance is running it pops an event in the eventlog and shuts down.

  • Windows Services are the way to go and beat task scheduler hands down in every respect.

    I have built an 'autoemailer' which fires of scheduled emails to clients and managers alike. It has been pumping out 300 - 400 emails a day based on both Oracle and SQL Server queries.

    I have a small MS Access app which front ends the scheduling.

    I also have written other .NET services to run a conveyor system, it has a .NET forms front end with event logs driven by Data Change Notifications ( no polling of database). These services have custom front ends to start / stop / pause / continue / custom commands etc without limitation.

    These services are
    1) Rock Solid
    2) Don't have to 'Start Up' any other applications or have any other dependancy on any other applications.
    3) Have been running for years
    4) Don't require the host computer to be logged on.
    5) Are easily maintained and administered by support staff.

  • Yes, I fully agree with the article, but what should I do, if I need the task to be fired every 10 seconds?
    Really simple task, which just check something and make a DB update... Windows Task scheduler is really good until you need to schedule in seconds.

  • Until scheduled tasks can run as background processes I heartily disagree. If you run a multitude of Windows Services as we do, 20 MS-DOS windows popping up every 5 minutes (even minimised) are a annoying interruption to an RDP session. I get your points, but your alternative is a equally as bad.

  • windows service hands down all the way... Even it's a daily job or weekly job.. monthly job, whatwever, windows service can handle it all.. and hardly takes up any cpu or resourse unless it's running a main process..

    if you don't know how or think that win service don't have that implementation, then you don't know how to write windows service.. u can even scedule it to run at a specific time too... just require 3 lines of code... man.. can't get any esier than that...

  • Since this thread has been brought to life a number of times...

    Windows task scheduler sucks. Lack of notifications. Lack of real error handling. Lack of job streams. General lack of ingenuity. Cron is a huge step up, but it still lacks the cross platform support.

    That's why there are companies that specialize in Enterprise Scheduling.

  • Would love to read an updated version considering Azure (or whatever cloud service you choose) along with VMs - but not targeted toward the enterprise but more for medium to tiny organizations.

  • Hi,
    I created a Windows Service using C#, I want to schedule it to run every night at 12am.
    How can I call this windows service from Task Scheduler?

  • Thanks in favor of sharing such a nice thinking, article
    is good, thats why i have read it entirely

  • Hi to all, how is everything, I think every one is getting
    more from this web page, and your views are nice in support of new people.

Comments have been disabled for this content.