Jump to content

Archived

This topic is now archived and is closed to further replies.

zhopkins

Client Task Not Executing - Operating System Update

Recommended Posts

We've setup a client task to install OS updates on a weekly basis to a select group of servers, but for several clients this task still shows as planned, never executed.  We've gone through two weeks now, and the task still hasn't executed, with seemingly no explanation as to why.

  • The client task runs the "Operating System Update" task.  "Automatically accept EULA" is checked, "Install optional updates" is un-checked, and "Allow reboot" is checked.
  • The trigger is applied to 25 individual clients, with a CRON schedule, "0 0 3 ? * FRI *" (Every Friday at 3am), no random delay, "Invoke ASAP If Event Missed" and "Use Local Time" are both checked.
  • The trigger shows "Planned - Yes" for all 25 clients.
  • The trigger shows "Last Status - Finished", along with a Last Progress Time and "Progress - Task finished successfully" for 17 of the clients.  The remaining 8 clients have these 3 fields blank.
  • All of the clients are checking in with the server at 5-minute intervals.
  • The status.html files on the clients are all green.
  • All of the clients are Windows 2008R2/2012R2, with Management Agent version 7.0.553.0.
  • The server version is 7.0.553.0.
  • All of the clients had at least 5 updates available and ready for install when the task was created.
  • The agent trace logs appear unremarkable.
  • Our timezone is US/Eastern, UTC-0400.

The trace log from a client not executing the task is devoid of useful information (I checked at least 3 of them, and they only show the one line from today).   I also checked a client that ran the task successfully last week, but had no further updates to install this week.  This client's trace log for today looked identical to the client that isn't running the task.

2018-09-28 12:03:51 Warning: CEssConnectorModule [Thread 178c]: Set policy request to product was successfull

The trace log from a client that did execute the task this morning, and successfully installed updates, looks to be chock full of details (file attached).

 

If anyone has any thoughts or suggestions as to why some clients aren't running the tasks as requested, they would be much appreciated.

Thank you!

 

eset-tracelog_clientwithupdates.txt

Share this post


Link to post
Share on other sites

Even when changed from a CRON expression to just a weekly event, the clients are still not running this weekly task.

Eset-WeeklySchedule.thumb.PNG.b7117d845e0cdef0128c26bafe007238.PNG

I can manually select any client, and add the task with an "As soon as possible" trigger, and the client will begin execution immediately, so the overall task is fine, its just that the reoccurring task simply doesn't run on a random portion of the assigned clients.  If anyone has any suggestions at all, it would be much appreciated!

 

Share this post


Link to post
Share on other sites
16 hours ago, zhopkins said:

Even when changed from a CRON expression to just a weekly event, the clients are still not running this weekly task.

Eset-WeeklySchedule.thumb.PNG.b7117d845e0cdef0128c26bafe007238.PNG

I can manually select any client, and add the task with an "As soon as possible" trigger, and the client will begin execution immediately, so the overall task is fine, its just that the reoccurring task simply doesn't run on a random portion of the assigned clients.  If anyone has any suggestions at all, it would be much appreciated!

 

Just for verification of one of our issues, in case you reboot affected machine, is task executed just after startup? It should in case "Run ASAP if missed" is enable.

Asking because we have identified issue, where trigger might fail in case there has been time shift (time synchronization) detected between events -> it means the more you plan  to the future, the higher probability is that this happens. In case this is the issue, it should be resolved in upcoming service release.

Share this post


Link to post
Share on other sites

Martin,

We restarted the ESMC server late last night, in hopes it would help the task to run at its scheduled time this morning.  That did not help.

However, restarting the client machines that were supposed to run the task, did help.  Once restarted, the client machines immediately began to run the task.  I also verified that the task UUID shows up in the trace log, and sure enough, it was right there on every single one (showing "generate a tick for a missed event", timer registration for the next occurrence, and the actual task execution).

Your note about this being more likely to happen as time progresses also seems evident in our environment - roughly a third of the machines missed the task on the first run, followed by half on the next run, and closer to 2/3 on the subsequent runs.

Thanks for posting, we'll be on the lookout for the next release!

 

 

Share this post


Link to post
Share on other sites

If a computer is turned off at the time of task execution and the task is configured to run ASAP, it will be run after the computer has been turned on or restarted.

Share this post


Link to post
Share on other sites
5 hours ago, Marcos said:

If a computer is turned off at the time of task execution and the task is configured to run ASAP, it will be run after the computer has been turned on or restarted.

Marcos, the clients in question are all servers.  They are online 24/7 and check-in every few minutes to ESMC.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...