KACE Product Support

In theory it should not matter. The kbox has been task based for a while so any tasks that are scheduled by the server, including patches, are subject to the throttling mechanisms and optimizations of the server.

If your throughput is set to X then the kbox will only allow a certain number of tasks so that value is not exceeded. So that would be about X dozen patching tasks -- or X dozen machines patching at once.

for a population of Y the other Y-X machines will be queued waiting for an open spot (completed task) to start their task.

IMO, all patches schedules should be set with a limit. So after a certain period of time the schedule will stop allowing news tasks to start. This will prevent the schedule (particularly schedules with a lot of patches) from spilling over into a time of day when you want other work to be done. The patching tasks that did not complete will be done in future iterations of the patch schedule.

So do not set X too high. If your system is humming along at 2 then you may consider increasing it to 3, but do not make the decision purely on your desire to run more tasks. Consider your internal benchmarks as well.

Your other considerations are network bandwidth - -can your network have X dozen machines downloading patches at the same time? Where are these machines?

I've been doing the patching for a little bit with the k1200. I've heard of a limit of about 500 machines patching, but I've never had a problem with patching. I've staggered my patching so I don't have to patch 2000 plus machine at one night. I've successfully done about 500 machines in one night. I would suggest organizing patches and limiting them based on what's out there in your environment.

ie windows 7 patches
windows xp patches
windows 7 apps
windows xp apps


Cheers,

M

All of the machines are on campus, so this would all be internal traffic. The KBOX is in our main server room with a very fast connection. I had forgotten about the throttling and queue mechanisms built into the KBOX (even though I attended a session on that at the Konference), so that allays some of my fears somewhat.

Thanks for the recommendation concerning suspending the patching tasks. I had debated turning on that feature for the following reason: We have patching set to begin on Thursday evening with the hope that machines will be left on that night (we sent out a communication asking users to do this). I have the option set to have machines patch the next time they check-in, so that they will begin patching the next day if left off. My concern is that if I suspend tasks, or not have them patch on the next check-in, that some machines will never end up getting patched. Would your recommendation be to run reports and catch those machines as they turn up?

After running the schedule even once you'll have a good idea at how long each machine is taking to patch and how many are left behind. The schedule can be tweaked from there either by reducing the patches or lengthening it's window.

If it were my kbox i'd let the schedule run with conservative limits at least once. If your motivation is due to some critical patches and you're still not sure of load then use a label to leave out other non-critical ones.

P.S. rate my posts if they helped!