Task Execution over 24 hours or 1440 minutes issue

Content Authoring BigFix.me
1

Hello All,

I am trying to deploy a powershell script that will run spread out of the course of 24 hours.

I set the action start time to be staggered over 1440 minutes as the powershell script involves some server overhead I wanted to really spread out.

I started the action at 5:07 PM Friday night, and as of 5:16 PM Monday it is just over 53% complete.

Can anyone weigh in on where I went wrong with my logic? 24 hours in a day * 60 minutes is 1440 minutes in a day, so that’s what I used.
I had a similar task set for another site and used 2880 minutes and its just over 27% complete now. Did I quadruple my minutes somehow?

See the following for the details on the first distribution. The task it self is small and quick and take only a moment to run.

Does the action End date come into play at all?

53.05% Completed (174 of 328 applicable computers)
Status
Count
Percentage

Completed
174
53.05%

Failed
1
0.30%

Waiting
120
36.59%

Not Reported
33
10.06%

Behavior
Messages
No user interface will be shown before running this action.

No message will be shown while running this action.

Users
This action will run independently of user presence.

User interface will be shown to all users.

Execution
This action ends 9/22/2017 5:07:47 PM client local time.

It will run at any time of day, on any day of the week.

If the action becomes relevant after it has successfully executed, the action will not be reapplied.

If the action fails, it will not be retried.

The action’s start times will be staggered over 1440 minutes to reduce network load.

Post-Action
No operations will occur after the action completes.

3

Just an update, these are still ongoing and now we have

4

And in case someone mentions it, I have read the literature I could find on the stagger start times, that it assigns a random time interval to the deployments. If there is a mechanism beyond that at play, I would like to understand.
…

…

5

The time stagger logic depends on a couple of things. First the endpoint has to receive the action and the start time needs to be met. At that point, the endpoint will randomly calculate a delay within the ‘staggered over’ minutes you specified. So part of the problem depends on whether your endpoints are online and received the UDP notification of the new action when it was first deployed. If not, it could be several hours (or days, if offline) for the endpoints to see the action and calculate the delay.

Unfortunately, there is also a bug in the stagger logic currently in 9.5.5 and higher that essentially doubles the time specified. So your 1440 setting would behave like 2880, and 2880 would behave like 5760. To achieve your goal for 24 hr stagger, use 720 minutes, and ensure that you deploy the action enough ahead of the desired start time so all (or most) clients will receive it and set the delay from the expected start time.

2 Likes
6

Thanks Steve!

I was not aware of the bug, that makes way more sense.

And I did not know the endpoints themselves calculated the randomness, so that it will randomly be within the time frame starting from whenever it comes online. I though the deployment itself created the random ‘ness’ logic and assigned deployments then.

I appreciate the clarification, it helps a lot :smiley:

1 Like