Ok, we have the current problem/scenario -- We manage about 1200 servers (a good mix of Linux and Windows) with KACE. When we patch, large numbers of servers get rebooted at the same time. What happens as a result of this is that we have large numbers of servers doing inventory updates more or less simultaneously when their inventory interval comes due. For us, this happens every 12 hours.

So, is there anyway that anyone knows to offset the client updates by say + or - few hours? Like a way to tell it to run an inventory update every 12 hours, plus or minus 2 hours?

Any tips or tricks no mater how complex or easy would be appreciated. (I am unable to change the reboot behavior during patching due to the constraints of our patch window).

Thanks in advance anyone for some help.

5 Comments   [ - ] Hide Comments


  • What is your inventory interval? If machines have checked in recently they shouldn't run an inventory update on restart.
  • My interval is 12 hours.

    However, when I look at most of the hosts, large numbers of them have the same/similar timestamp for their last inventory update. Additionally, the box has a low load most of the day, but, every 12 hours, gets hit with a larger load when these groups of hosts check in. I'm looking to even this out.

    So if a restart does not define when they will check in next (as in starting the countdown to the next check-in interval), what does?
  • You could disable automated service startup for the KACE Agent and instead schedule the service startup at staggered intervals. In my experiences, the Agent checks in as soon as it starts and that starts the timer for the next checkin.
  • I have to agree with grayematter, the check in should happen when the machine boots up. Then it will check in every 12 hours as you have it set up

    This is a out of the box way but you could call support and request a new key that enables ORGS. With ORGS you can create separate check in times for the servers that belong to that ORG.

    ORGS are typically used by MSP for mulitple clients as they act as separate KBOX's with in one KBOX. They are considered separate so there is no mixing between ORGS. A little more work on your end to create mutiple schedules for each ORG but could solve the problem for you
  • Ok, so I was looking at the behavior of the agent in regards to inventory updates. And, as chucksteel suggests, if I force an update on a machine, then reboot it, it honors the update pre-reboot, meaning it does not re-inventory when it comes up.

    If this is the behavior, then I can work with this, and will just stagger agent updates across all my servers in small batches so they check in every 12 hours, but they all don't check in at the same time, every 12 hours.

    What we're seeing now is that all 1200+ machines try to check in at more or less the same time every 12 hours. This means the CPU is 100% idle most of the day, then get slammed when everything checks in.

    What i am trying to accomplish, is to have a few boxes checking in all the time over the course of the day.

    Anyway, thanks for the help thus far everyone.
Please log in to comment

Answer this question or Comment on this question for clarity


It sounds like you are talking about the Patch Schedules rather than the Inventory schedule. 

FWIW- Setting the Client Inventory to 12 hours just means that the machines will check in and perform Inventory Tasks at some point in the 12 hour interval while it is connected. This is automatically spread out over that interval and if a machine is missing or becomes overdue it will check in the next time it is available. 

Patching is very different. It is explicitly scheduled for a set of machines to receive a set of patches (when I use 'set', think 'Label(s)'.)

Navigate to Security -> Patching - Schedules and look to see which machines are scheduled for various times. If too many machines are rebooting at the same time, you may want to break up the Device Labels into smaller groups and create more schedules within the Patching Module. 

Answered 10/22/2014 by: MacDude
Fifth Degree Brown Belt

Please log in to comment