Windows Azure Task Scheduler

July 8, 20118 Comments

Task scheduling is not a built-in feature of Windows Azure, but the Windows Task Scheduler is still available on Azure virtual machines.  With a small batch file and a couple of settings, you can implement task scheduling quickly and easily.

In my solution, I added a batch file called TaskScheduler.cmd to the Worker Role project.  The batch file starts the Task Scheduler and then creates tasks using the SCHTASKS Windows command.  You can also use the AT command if you prefer.  For this file, the property Copy to Output Dir should be set to Copy if newer.

You do not need to worry about restarts, the batch commands I used will ignore duplicate requests.


@echo off
REM ********************************************************
REM Start the Task Scheduler Service
REM ********************************************************
net start "task scheduler"
REM ********************************************************
REM Create scheduled tasks.
REM ********************************************************
SCHTASKS /Create /SC MINUTE /MO 30 /TN MyTaskName /TR "e:\approot\myconsoleapp.exe" /RU SYSTEM /F /RL HIGHEST


On the last line of the batch file, you can see that I’m referencing “e:\approot.”  That is the location of your executables after your project is deployed to the Azure virtual machine.  That location could change in the future so you’ll need to monitor Azure platform updates.

Remember that this batch file will run on each instance of your worker role.  If that is a problem, you’ll need to figure out a way to manage these tasks across multiple machines.  In my case, even though Microsoft doesn’t recommend it, I am only running a single instance.

Startup Tasks

This topic is covered in much better detail elsewhere, but I’ve included a snippet from my ServiceDefinition.csdef file to get you started.  The “startup” block tells Azure to run my batch file when the worker role is started.

<workerrole vmsize="Small" name="MyWorker">
<task tasktype="background" executioncontext="elevated" commandline="TaskScheduler.cmd">

Console Apps on Azure

Although it would also be easy to include and run another batch file in this project, my example shows that I’m running a console application.  If you haven’t tried this, it’s very easy to do.  Simply create a console application project in your solution.  Then, go to your worker role project and add a reference to your console project.  The console executable will be copied to the bin directory of your worker role during each build.  The console app’s config file can be added to your worker role project as well, just like we did with the Taskscheduler.cmd file.  If you set the Copy to Output Dir property on the file to Copy if newer, it will be copied to the bin directory.


I haven’t experienced any failures in using this approach yet, but it’s a good idea to check out your virtual machines once they’re running.  Make sure you enable remote access in the Azure portal so you can login to each VM.

That’s all there is to it.  I noticed a lot of people requesting a scheduler within Azure, and maybe that’s coming, but this approach works well in the meantime.



8 Responses to “Windows Azure Task Scheduler”

  1. Jack says:

    Couple of problems I noticed:

    1. Drive for approot changed from E: to F: when I did an upgrade on the worker role. Which basically throws everything thing out of whack.

    2. Cannot access Azure diagnostics (like Trace) from the console app (called by Task Scheduler) because its not part of the worker process.

    Also the app.config for console app is not copied as appname.exe.config to the output folder.


  2. Shannon Whitley says:

    @Jack – Thanks for the note.

    #1 – I’ve consistently had an E: drive, but I noted that this can change. You may need to make adjustments for different VMs.

    #2 I should note that I set the name of the config file to {appname}.config.exe. You’re right that the project will not change the name from app.config. You can also include a post compile command in the exe project to continually update that file.

  3. Jack says:

    @Shannon great article and thanks for the reply.

    Were you able to write trace logs using azure diagnostics from the console app?

  4. Jonas says:


    Another approach on #1 is to use scheduler to call an console app which sends a single message to an SB queue which the worker roles listen to.

    If you use duplicate message detection it will also work with multiple instances.

  5. JasonBSteele says:

    Use %~dp0 for the application root

  6. Andrew says:

    @Jason – is this a hidden system variable?
    I don’t see it listed when I remoted into an azure instance.

    Would I be able to test this by using run -> open -> %~dp0

  7. Used this and had a couple of problems, but I had fixed it when I saw the problem in the comments section and then solved. Thank you for sharing this with us! Great work and keep it up!

  8. miliu says:

    Is it possible to use this approach to “silently” install a component? I quoted silently because it’s actually an InstallShield setup and I use AutoIT script to automate UI navigation. It looks to me that in startup task or (scheduled task) UI element is suppressed so that AutoIT scripting will not work. Is this correct?

Leave a Reply

Twitter Tweet This