You could schedule a script that stops/disables to Intel Local Scheduler service on those devices for the time being. This local scheduler is the source for all local activity (Inventory/Vulnerability/Policy Sync) on the device. Besides that one, I would also stop/disable the LANDesk Targeted Multicast Service, as this may listen to requests from other devices for perr-to-peer download. Also be sure nothing is targetting the devices from the Core Server. Finally, be aware of the Agent Watcher options in your deployed agent. This may automatically restart the services.
Be careful that when you put all services to run automatically again, to use a script or push-task, as a policy delivery will never be processed
I am using 9.5, so I'm not sure if this is available for you to apply in 9.0sp2. We just started using this product and I have never used 9.0. Anyway, I am running into a similar issue of users complaining about slowness. The culprit was vulscan.exe process. Killing this process returns the machine to normal. But of course, by design, the agent kicks off the scan again. Frank is onto something with stopping the services, but that will keep you from delivering an emergency patch until the machine reboots to start the service.
I ended up making a separate agent configuration by only allowing the agents to scan everyday from 9PM to 6AM and then sending out an "update to agent configuration". You'll need to uncheck "when user logs on". Keep the mini scan for when an IP changes though. Do the same schedule for the "Patch and compliance scan". That will cover you for the inventory and vulnerablity scans. However, there is a flaw with this method. If the machine is always off during the time you have it scheduled to allow for scanning, it will never be scanned. You could query for machines that haven't been scanned in so many days and revert the config by scheduling an update to agent settings and applying that query to the task.
As far as the policy sync, you can't turn that off, at least not that I am aware of. But again, you want that available all the time if you need to apply an urgent patch. What you can do is make sure you don't have any policy tasks running for the clients to check against, e.g. Policy Supported Push. I think you'll find that with changing the schedule, your clients will stay within normal resources anyway. Hope this helps!
if i understood good the original question was to stop LANDesk during relatively short periods of high network volume.
Your settings may work good in your situation, but as a permanent solution it has all 'dangers' you mention if devices are never on between 21 and 6. By temporarily stopping the services it is always still possible to push applications, patches or scripts (like the one to turn on the services again, not needing a reboot.), no need to rely on policies.
Thank you very much Frank!
My stores' are facing an onslaught of activity during black Friday and the proceedeing weekend. They are WinXP Embedded machines with only 1 stick of memory.
This will be a huge help in reducing client side load as the previous manager decided to have the vul/inv scans occur from 12pm-1pm. With all our stores, it sometimes takes upwards of 4 hours to complete their cycles!
Late to the game on this one, but rather than stopping on the client and all the fun that entails, if you are specifically concerned about Inventory and Vulnerability scans, you could just disable the services on the core temporarily.
Stopping the inventory service on the core means clients will not run the scan at all.
In IIS stop the LDAppVulnerability application pool means there is nothing for the vulnerability scanner to connect to either.
A single place to disable and then re-enable when you are ready.
MarXtar Ltd/MarXtar Corporation
LANDesk Expert Solution Provider
The One-Stop Shop for LANDesk Enhancements
Update - New Stand-Alone State Notifier Console for Service Desk Operators
Update - State Notifier now detects machine and user Idle states
Update - WoW & State Notifier now integrate for even more functionality