1 2 Previous Next 16 Replies Latest reply on Jun 21, 2018 5:44 AM by phoffmann

    Schedule Time Creep Issue

    tsujared Apprentice

      One thing we have noticed is that when you schedule a recurring task, the time scheduled creeps. For example if i schedule a task at 7AM and repeat every day, it will run the task and then reschedule 1 day from completion of the task not from the initial scheduled time. So if the task takes 30 minutes to run then the next scheduled time to run is at 7:30AM the next day. Well this is an issue because these reoccurring tasks we schedule are designed to be ran outside of regular business hours. With the time creep it will then begin running during production hours, thus impacting the users during peak hours. This should not be the way it is. The time should always be the time from the scheduled time, not the end time. That makes 0 sense. This also impacts running stuff in a maintenance window. Someone else has to have this issue too? Please fix this. seattleman1969

        • 1. Re: Schedule Time Creep Issue
          phoffmann SupportEmployee

          It's explained here -- Local Scheduler and being aware of time creep .


          You can "fix" / control it perfectly fine with logic as is.


          The reason why you want to be REALLY careful with a "start at this time & this time only" approach is that you can run into multi-instance executions (i.e. you start a task at time X. By the time the next interval comes along, the task hasn't FINISHED yet ... and you start a 2nd instance ... which can cause a whole heap of problems).


          Both approaches ("starting at the END time" as we do it, or "ALWAYS starting at the configured time") have drawbacks & benefits.


          This is simply a matter of education & knowing about how to configure your task. It's not a defect.


          It's a simple design choice which is going to work in a safer approach for most, but is going to cause grievance to some others (both approaches do). However, this can be controlled perfectly fine with filters & condition logic already present.

          • 2. Re: Schedule Time Creep Issue
            tsujared Apprentice

            ok I read the link you sent and it makes a point but the time creep is still an issue. Lets say I schedule it to run at 7:30am and repeat every 12 hours and it takes 30 minutes to complete. Then i confine it to between 7am and 8am. The time creep is going to make it where it will not run at all because it will fall outside the window. Unless I am missing something, I don't see how it would run again. I don't understand why i just can't have the option to say run everyday at 7:30am and 7:30pm and I don't care how long it takes to run. Plus some computers will run the task quicker than others and now all the sudden you have computers running tasks at random times and out of sequence. So yes while the creep may be a feature, it is more of a nuisance. What is so difficult about having a reoccurring task run at a specific time and not a random time based on time to complete?

            • 3. Re: Schedule Time Creep Issue
              phoffmann SupportEmployee

              It's a problem VERY easily fixed.


              Use the logic features available to you.


              Here's how.


              Let's say you want to start the task 2x per day - once between 07:00 and 08:00 in the AM, and then between 22:00 and 23:00 in the evening.


              Here's what you do:

              • Task 1
                • Time of Day filter - 07:00 - 08:00
                • (or 05:00 - 06:00 with 2-3 hours of random delay for instance if you want to spread things out & not have every device start at 07:00 if they're on)
                • repeat every 20 hours (or even "every 4 hours if you want).
              • Task 1 result:
                • after your 20 (or 4) hours after the task has finished, it's primed again for running.
                • HOWEVER, until the TIME OF DAY filter is matched, the task will not run.
                • So the task will run - every day - at your defined time (because it'll be "primed to run" before the 24-hour period "after I last finished" has started).


              ... and create a 2nd task with much the same for the evening / 2nd time run.


              Simple .




              The problem with "what's so hard about..." is - as I described above - that "you" (as in "people") will configure a task that'll end up running into multiple instances (usually sooner rather than later). More often than not, this can cause VERY nasty side effects, as a lot of applications / script-jobs don't have logic to handle that.


              In some cases, this "just" causes massive load issues (think "running multiple DB backups or re-indexing jobs in parallel" which is always fun when I see it), and in worse cases, the application in question will crash / get confused, or - worse - start corrupting things / itself.


              This is the lesser (and safer) of the evils. The amount of harm that people can bring upon themselves with the latter (and you'd be surprised how quickly such a thing would be "our fault" even though it wasn't us that configured the task in question), it may be the less convenient, but it's definitely safer.


              And safe is good.

              • 4. Re: Schedule Time Creep Issue
                tsujared Apprentice

                I get that and can see where that would be an issue. However, I would still like the option of saying I want this task to run at this time every day no matter what. Still seems to me the way you are describing it is that I would still run into issues of it falling outside the time allotted without having some huge windows or it to fall into. That is something I wish to avoid as I have other tasks that run at varying times. Maybe from a developer standpoint it makes more sense to you, but from a tech and user standpoint it makes more sense to me to just let me schedule things when i want. Again it goes back to different machines will complete a task at different times, and that in itself can cause an issue.

                • 5. Re: Schedule Time Creep Issue
                  phoffmann SupportEmployee

                  Heh - (un?)fortunately I'm not a developer, just a TAM. So I'd argue I'm very much a tech/user standpoint.


                  My perspective is one of having had far too many clean-up jobs of the "working as configured, not as intended" side of things (Management software gives people a LOT of power ... sometimes, not everyone thinks things through quite as far/well as they should). So I prefer something that errs on the side of caution. I came up from support, and having seen people (unwittingly, granted) perform resume-generating moves, I'm a big fan of safety nets overall.


                  I personally don't quite see how a task could fall outside of its alloted time (shy of you having a "you MUST complete in 30 minutes or less" type clause, in which case I'd suggest you have a wrapper that keeps an eye on the runtime of your task & shoots it down if needed). Could be because I'm still groggy or just not seeing the forest for the trees here, so I'd be happy to take on whatever example it is you're thinking of.


                  If you lay out what you think your problem child is in more detail, I'm pretty sure we can come up with some way to rock that one to sleep.




                  However, you certainly can get an enhancement request going for the "launch at this time, and this time only" (even though you already can I'd argue, but personal flavouring & all that). To do that, follow the process starting from here -- Enhancement Requests .

                  • 6. Re: Schedule Time Creep Issue
                    tsujared Apprentice

                    well i didnt mean to refer to you as a developer, just using that in the sense of how it was designed. Also they do not make these things very intuitive to the users of their product who haven't been on it for very long. Basically my situation is I have many tasks that run on a schedule. Patching, content replication etc. Our patching occurs twice a week in a roll out project during off hours. We are a university so our hours are not the normal 8-5. Our labs and classrooms open at 7:30 in the morning and classes go til 9pm and computers labs open til midnight. Though after 9pm it slows down. So our content replication occurs between 9pm and 7am. The task I want to run takes roughly 5 minutes or so. but i need it to stay in the 7:30 to 8am time window and then again in the evening at 7:30-8pm. this way it does not try to run as other things are running. so after 6 runs it will fall outside the 30 minute window and thus not run with other things running. that make any sense?

                    • 7. Re: Schedule Time Creep Issue
                      phoffmann SupportEmployee

                      It does - but again, it's entirely solvable with the logic I described.


                      So here's what I understand your needs to be:

                      • Run job 1 betwee 07:30 and 08:00 am every day.
                      • Run job 2 between 19:30 and 20:00 in the pm every day.


                      So how would we do this? (This example is for task 1)

                      • Run - every 20 hours. (so that the task is "primed" before the 24 hours + its runtime are up).
                      • Run only between 07:00 - 08:00 (so even though the task is 'primed', it will ONLY be launched between 07:00 - 08:00).
                        • You can THEN use either our own default random delay thing (say min 30 miutes, max 55 minutes), or do your own wrapper script that checks the local time & responds to that.
                        • The "wrapper" script would prevent you from running into situations where a device had been powered off & only powered back up at 07:45 which WOULD BE in the 07:00 - 08:00 timeframe, but then the minimum 30 minute delay would push it over 08:15 which you don't want.
                        • So - based on your more specific needs, I'd suggest you have our scheduled call your wrapper script which can then do more sophisticated decision making (since yours seems to be a rather uniquely sensitive time-situation).
                        • You can use separate "tricks" to even stay posted on how your devices are doing. See for instance something I've come up with here -- About SDCLIENT based communications -- for a customer that needed to keep track of when certain devices would START and/or FINISH with their inventory scans.


                      ... by and large, not that difficult. And with the use of the TimeOfDay filters & a "less than 24 hour" repeat-cycle, you don't really have any time-creep to contend with.


                      Does the logic of it make sense to you? Understandin that *ALL* of the filter conditions must be true for a task to run can be a GREAT help (or hindrance, I've seen people configure themselves into situations that'll never be true) in fine control of this.

                      • 8. Re: Schedule Time Creep Issue
                        MarXtar ITSMMVPGroup

                        Hi phoffmann,


                        Did I dream that this was fixed? I'm sure I saw something about this being fixed in an SU or version update and even remember testing to find that it had actually been fixed. Can't for the life of me find the article that mentioned it.


                        It was definitely being treated as a bug at the time rather than a design benefit. Did I really dream this or did it 'time creep' back into the product?


                        Mark McGinn

                        MarXtar Ltd/MarXtar Corporation


                        Ivanti One Development Partner


                        Try MarXtar Enterprise Notifer for Ivanti to Better Communicate with Your Service Subscribers

                        Try MarXtar State Management for Ivanti to Better Understand and Manage your Assets

                        • 9. Re: Schedule Time Creep Issue
                          phoffmann SupportEmployee

                          That what was fixed?


                          The suggested way to work around the problem of creeping start times because of run-time that I've given would've worked for years, as it's just using logic to configure the relevant task.


                          Nothing was broken that I'm aware of ...?!?


                          <And If the thinking is "it should always start at the same time", I've got a lot of situations where people would've gotten themselves into a fairly dangerous pickle by that. So as occasionally awkward as our design preference is, it's the safer way. Doesn't mean that a little application of logi can't make your task behave in exactly the way you want it to. >

                          • 10. Re: Schedule Time Creep Issue
                            tsujared Apprentice

                            Your solution is slightly more complex than a little application of logic. And push come to shove anyone can get themselves in a pickle given any set of circumstances. You just can't make it so difficult on everyone to try to save the few from themselves. Either way, your solution does not provide the solution i need. That solution is that my task I set kick off at the same time everyday as I schedule them.

                            • 11. Re: Schedule Time Creep Issue
                              phoffmann SupportEmployee

                              If you need it to run at "time X and time X only", without ever deviating, use Windows Scheduler. That does not care about other instances running / similar things, so will do what you need it to.


                              Again, both approaches have their own benefits & problems.

                              • 12. Re: Schedule Time Creep Issue
                                tsujared Apprentice

                                So wait, you are telling me to use windows scheduler to get Ivanti UEM to run a task that is only available in UEM? Explain how that makes sense. This software was over $150K and it can't do something as simple as keeping the start time of a reoccurring task?

                                • 13. Re: Schedule Time Creep Issue
                                  MarXtar ITSMMVPGroup

                                  Hi Jared,


                                  Can I step back a bit here and make sure everyone is talking the same thing.


                                  Are you talking about tasks you have scheduled locally on the client or are you talking about tasks you have scheduled centrally on the server. I don't see that you specifically identify reading back in this thread.


                                  If you are scheduling locally, have you instead tried scheduling centrally? A centrally scheduled task shouldn't be slipping anymore (it used to but that is what I remember changing). Even in a very large environment it should be possible for it to contact each device that is online within the window you need. Also if you have a pretty frequent policy check interval and have it setup as a policy supported push then you have the belt and braces of policies picking it up. Locally scheduled tasks may seem the obvious thing to use but they weren't actually designed to do specifically what you are trying to do here even if it seems like they should have been. Would the alternative I've suggested work, or is this actually what you are struggling with?


                                  Mark McGinn

                                  MarXtar Ltd/MarXtar Corporation


                                  Ivanti One Development Partner


                                  Try MarXtar Enterprise Notifer for Ivanti to Better Communicate with Your Service Subscribers

                                  Try MarXtar State Management for Ivanti to Better Understand and Manage your Assets

                                  • 14. Re: Schedule Time Creep Issue
                                    tsujared Apprentice

                                    so what i am trying to run is a task from UEM, in this specific case a data analytics rule. it can only be ran from UEM. but what happens is if i schedule it at 7am and repeat daily then the next scheduled time is 24 hours from completion not 24 hours from the start time like i want.

                                    1 2 Previous Next