========
SchedCDB
========

December 29, 2010


SchedCDB shows how to use the new Task Scheduler API in Vista and later
versions of Windows to schedule a deferred task from a VB6 program.  It
doesn't demonstrate all of the features available, but it should be a
useful starting point for more elaborate requirements.


The Demo
--------

When you run SchedCDB you can fill in several parameters and schedule
the CreateDB program as a scheduled task.

CreateDB creates a Jet MDB and populates a table in it with a specified
number of records containing random data.  This program has no User
Interface, so parameters are passed to it via the command line.

The program runs unattended and logs its progress into a log file.  The
unattended flag should ensure that any exception is logged there as well
instead of raising any dialogs.

CreateCDB "takes a breath" every so many records by calling Sleep.  This
is meant to help space out its duration a little for demonstration
purposes as well as to free resources during the "batch" run.

If SchedCDB is run elevated it offers the option of running the
scheduled task elevated as well.  This is not required, but merely a
demonstration of the feature.


Real Applications
-----------------

In a real application your "SchedCDB" program would probably have more
information to pass on, and your "CreateDB" would do more work and maybe
leave more extensive results behind.

You would probably also want to avoid creating files in or under
App.Path because installed programs won't normally be able to write
there unless elevated.  A subfolder created under LocalAppDAta or
CommonAppData makes more sense, or perhaps even under the new (for
Vista) Public folder.

One idea might be to pass parameters from your scheduler to your worker
program via a file.  Results of course might return via a file, files,
or a folder of files created by the worker in return.  At that point you
might use the command line arguments to pass the in/out file/folder
names from scheduler to worker.

You also won't usually need as many scheduling options.  Probably using
S4U instead of a user/password is enough.  You probably know ahead of
time whether to run the scheduled task elevated or not, etc.  In most
cases you'll just need a StartBoundary time, and from there perhaps
calculate a reasonable EndBoundary (see the sample code).  Those define
the "window" in which you want the task to start (or give up).

Other options not explored in this demo include cyclic tasks, those run
repeatedly every "interval" in hours, days, etc.  But those can easily
be set up manually in most cases, via the wizard in the Task Scheduler
Management Console.  However you could also create a program to make
that easier too, as well as interrogate scheduled tasks to display
their status.


Triggers
--------

This example uses a Time Trigger, but you can also use a Registration
Trigger to start a task immediately (or after a delay), a Daily Trigger,
Weekly Trigger, (Log) Event Trigger, etc.


Build Instructions
------------------

Just compile the two programs, make sure the EXEs are in the same
directory.

This should be a read/write location since the logs folder and the
database will be created there.


Run Instructions
----------------

Run SchedCDB (or run it elevated).

Fill in the parameters, especially the "Records to write" (number of
records to add to the database).  That field is not error-checked and
leaving it blank will result in a failure of CreateDB (bad command
line parameters).  This in itself can be a useful test.

Values such as 100,000 (no commas) or greater can be interesting since
they take a bit of time, but testing with 1000 works fine.


Notes
-----

1. Only members of the built-in Administrators or Backup Operators
   groups can schedule tasks.  Elevation is not a requirement however
   (see 2. below).  "Home" editions of Windows normally don't have the
   Backup Operators group.

2. To schedule a task to run elevated SchedCDB must be running elevated.

3. The task is scheduled with an ExecutionLimit of 20 minutes.  Very
   large values for "Records to write" might exceed this.

4. When the task is scheduled with S4U ("Service for User") credentials
   it can run as the current user without storing a user/password in
   the scheduled task itself.  However when run this way network
   services and encrypted files are not accessible to the task.

5. If you don't use S4U, a user/password must be stored.  For things
   like recurring tasks future password changes may require that you
   update the password in the schedule task.

6. IF YOU WANT THE SCHEDULED TASK TO RUN AFTER LOGOFF, the user must
   have "Log on as batch job" rights (policy setting).  This is a local
   group policy setting.  The free 3rd party tool "polsedit" can be
   handy for this, particularly on "Home" editions of Windows:

      http://polsedit.southsoftware.com/
