I – Introduction
The LANDesk Local Scheduler is a very powerful client-side component that is very popular and sees wide usage.
Yet at the same time, it is one of the most easily misunderstood components of the LANDesk Management Suite. The effects of such misunderstanding can range from being a negligible matter to being of serious impact indeed. Not to make too fine a point out of it - it is theoretically possible to configure your tasks in such a way as to ensure that they will never – EVER – run. Or, respectively, run without end.
With the Local Scheduler being such a powerful tool, informed caution is well advised. However, the focus here is not in cautioning, rather it is to inform, to educate.
This article aims to clarify one of the most commonly misunderstood processes of the Local Scheduler, and bring to attention the importance of using time-filter constraints – particularly in bandwidth/timing-sensitive environments.
That frequently misunderstood process is the timing and repetition of tasks.
II – Local Scheduler basics – how to read local scheduler tasks:
There are primarily two ways to read data concerning Local Scheduler tasks.
The first (covered in II.A) is centrally – on the Core, as part of a clients’ inventory. The second (covered in II.B) is to generate an output-file locally on the client itself which can then be read in your text-editor of choice.
Both are quite viable. Both are demonstrated here, as certain situations may call for one (or the other) to be more convenient or more effective when querying a client directly.
II.A – How to find/list Local Scheduler tasks on a Core:
For several versions now, LANDesk has been reporting all Local Scheduler tasks into inventory, and this information (individual to each locally scheduled task) can be found in any devices’ inventory as shown in the screenshot below.
In the screenshot below, the *RED* section serves to guide where in inventory this information can be found, whilst the *BLUE* square indicates the properties/details of that particular local scheduler task.
![Core_Local_Sched_Tasks_Modded.JPG]()
The meaning of the various task details will be discussed and clarified further below (in section II.C - HERE ).
II.B – How to find/list Local Scheduler tasks on a Client:
NOTE: To get an output of local scheduler tasks into a text file run the following from the LDCLIENT-directory (By default – "C:\Program Files\LANDesk\LDClient\" or - for 64-bit systems - "C:\Program Files(x86)\LANDesk\LDClient\" ).
Localsch.exe /tasks >mytasks.txt
![Client_LocalSched_Tasks_Modded.jpg]()
II.C – What do those terms (handler, filter, frequency, etc.) mean exactly?
Some parts of a Local Scheduler task may be more intuitive than others – as a result, I will go through the various sections, and have highlighted the crucial bits of information in colour-code so as to match the screenshot presented in II.B.
II.C.1 – A complete Local Scheduler task
This is simply a “complete” Local Scheduler task entry from beginning to end. In the output-file, the separation can be simply done by the listed number in the first space of an entry.
II.C.2 – The task handle
This is a unique identifier for a task, which is used when a particular task needs to be deleted or modified, for example.
Certain task ID’s are treated as reserved (and task ID below 1,500 should be regarded as reserved), with “normal” user-generated tasks usually having six digit handles (so as to better separate them from “reserved” tasks).
One of the reasons we start with such high, six-digit numbers is to prevent any problems with legacy clients, where smaller numbers were used.
II.C.3 – The task frequency
The task Frequency is based on the number of seconds between repetitions of a task. Most tasks have a value of either 3600 (1 hour) or 86400 (1 day) as a frequency, but any sensible positive value is acceptable.
IMPORTANT NOTE– don’t panic when you see a frequency of “1” in the screenshot above. That particular task has got an additional filter (see below) that activates the task only when the IP-address changes.
II.C.4 – Task Filters
Task Filters are additional conditional clauses you can attach to a task to give you more control under which conditions a task is run. Most commonly this is a filter based on the time of day (i.e.: “only run between the hours of 01:00 – 04:00).
It is important to point out here that filters are purely based on the CLIENT’S perception of things – i.e. its own local system clock, and so on.
Additional filters such as “on IP change” or “when no user is logged on” are also popular, and for a full list, I would recommend that you go through the Local Scheduler task UI (In “Manage Scripts”, you can create Local Scheduler tasks) to get a taste for what is possible. The screenshot below should hopefully help with any remaining confusion on where this is.
![LocalSched_CreateTask_Modded.JPG]()
Note:ALL filters must be true for a task to run. There’s a distinct AND logic here, and a task will not run until ALL filters’ conditions are satisfied.
Therefore, be thoughtful when applying filters. Ask yourself if this is what you truly want, what you truly need – it’s a simple enough thing to misconfigure oneself and end up in an undesired state.
Local Scheduler will do EXACLY as it is configured to by you, not necessarily as you intended!
II.C.5 - A “bad” example of using filters:
Since a task will ONLY trigger when ALL of its filters are true, let’s demonstrate how one can use filters badly, so as to never have a task running.
If you were to configure a task to run between 02:00 and 04:00 in the morning, and have an additional filter that REQUIRES a user to be logged in but this ends up being a condition that is never met (as people may not work in such late/early hours), you would end up with a task that never runs.
III – Task reruns and “the time creep”:
The most common misconception in relation to Local Scheduler is that the frequency of a task is based upon its START-time. In other words. – if a task is set to start at 10:00 on day 1, the expectation is that it will always start at 10:00, assuming a frequency of 1 day (86,400 seconds) is used.
Little could be further from the truth!
In fact, the frequency kicks in based on when a task has last FINISHED! So - if a task starts at 10:00, then has a 15 minute long random delay (10:00 => 10:15) and a 10 minute long runtime (10:15 => 10:25), the 1-day delay will apply to the end-time of 10:25.
This “time creep” is something of which you should be aware, as this will inevitably send tasks spiralling throughout all possible times. This is particularly likely if you’re combining long-running tasks with large, random time windows.
The best way to counter-act this is by confining tasks to run in a certain time-window. This shouldn’t be used too narrowly, as a long-running task with a narrow time window will cause loss of days very quickly.
As an example, the following table shows what can happen to a task with the following settings:
• Task must run between 10:00 and 11:00
• Task has a random delay of 0-60 minutes
• Task has a runtime average of 10 minutes
| Running Day # | Start Time | Random Delay | Duration | End Time | Next Effective Start |
|---|
| Day 1 (Start of the task) | 10:00 | 15 mins (Runs at 10:15) | 10 mins | 10:25 | Day 2 - 10:25 |
| Day 2 | 10:25 | 27 mins (Runs at 10:52) | 10 mins | 11:02 | Day 4 - 10:00 |
| Day 3 | 11:02 ** N/A | --- | --- | --- | Day 4 - 10:00 |
| Day 4 | 10:00 | 40 mins (Runs at 10:40) | 10 mins | 10:50 | Day 5 - 10:50 |
| Day 5 | 10:50 | 35 mins (Runs at 11:25) | 10 mins | 11:35 | Day 7 - 10:00 |
| Day 6 | 11:25 ** N/A | --- | --- | --- | Day 7 - 10:00 |
** Notice that we do NOT run the task on day 3, nor on day 6.
This is because 11:02 (Day 3) // 11:25 (Day 6) is ‘outside’ the TOD (Time Of Day) filter set to run the task between 10:00 and 11:00. What happens now is that whilst the task is “active”, we check every 20 seconds (default) to see if the filters are all OK. In other words, we wait until 10:00 am the next day to run/start it again.
IV - An Important clarification on START TIME:
* A task is deemed to have started as soon as its random delay kicks in. It doesn’t matter if the random delay pushes the task outside the time-constraint boundary (such as 11:25 for instance, in the above example, on day # 5). The task STARTED in the acceptable time-boundary, and the random delay is not deemed a factor here.
* A task that will END outside of the acceptable time-frame (such as 11:02, as on day # 2 in the above example), will still be checked on the next day for running conditions. However, since – in the above examples – there’s a constraint for a task to run from 10:00 to 11:00, the task will idle with the Local Scheduler continuously checking whether all filters can be satisfied.
* In this example, this is true on day # 4 at 10:00, since the task “started” (but was not LAUNCHED) on day 3 at 11:02 as the 10:00 – 11:00 filter was not satisfied … so the task was continuously active for just under 23:00 hours for all filters to be satisfied and finally being successfully launched.
* It is for this reason that one should be mindful not to use too many filters for a single task. The more filters that are used, the more conditions need to be simultaneously met, thus increasing the chances that one ends up with a task that will never run because all of the filter conditions CANNOT ever be all true at the same time.
IV – Conclusion:
With the information provided in this article, the reader should be more informed about some key points when using the Local Scheduler. It should be clear why task filters should be used with care, and why particularly the “Time Of Day”-filter is an important utility in overcoming the time-creep issue.
