I got exactly the same problem. I am on hold with tech support right now and will post the solution.
Can you post your script? Also, why not use an executable package rather than a custom script? If you want to do more than one thing you can always use the option to use a preliminary/main/final package when scheduling the task. Also, if you do continue to use custom scripts, try modifying the Custom Jobs options in Configure Services to reduce the number of retries, the discovery options used, and potentially the timeout. This will reduce the impact of the off machines.
Mark Star - MarXtar LANDesk Enhancements
Home of Power State Notifier & Wake-On-WAN for LANDesk
Sample script below. This is the script automatically created by deploymernt of a patch
; This file was generated by Desktop Manager
REMEXEC0=<qt/>%LDMS_CLIENT_DIR%\VulScan.exe<qt/> /repair "vulnerability=MS08-067" /agentbehavior=4 /taskid=%TASKID%, STATUS
See Attachment screen shot for Custom Configuration settings
CusJobSettings.bmp 993.8 K
Mark, this is really directed to you, but any answers are appreciated.
I know this is an old conversation, but I just put in a new server with 9.5 SP1. I ran our first Scan and Repair Task and it's taking over 4 hours for 1300 systems. When we had 9.0 SP3 it took less then 2 hours from start to finish for the 1300 system. All my settings in custom jobs are the same as it was in the 9.0 server.
Yes, I do see some of the errors of my way in the settings, after reading more about it. I see how I could improve on it. But, I would like to know why it's taking over 4 hours now, if the same setting are used. The task was set to wake up computers, did something change in the algorithm in the total process. I send to 61 systems at a time, wait 300 seconds for the system to wake up etc. Discovery 3 reties at a timeout of 1.5 seconds. It uses both TCP and UDP for discovery and DNS and Subnet Broadcast are NOT disabled. I think I'm going to change it to use just UDP.
Also the scheduled task log should show, if it used the Magic Packet or AMT power on, not say either one was used to wake up the system. This causes me to want to know the total time allowed for wake up. Does it send, Magic Packet and not turn on, then send AMT power on. If that is the case, how long does this process take. We do configure Vpro on our systems.
I think the total algorithm process has changes from start to finish to present this amount of increased time for the same task.
Any info is welcome.
The wake process is not well documented so I don't know how it follows the process. I do know it will try all wake options available, WoL, WoW and vPro where available but how these add up is not clear. If you set up preferred subnet representatives you might find the speed increases. I'm not a big fan of the LD WoW implementation since there are not enough configuration options to allow us to disable it to rule the whole thing out.
There are obviously some underlying changes in the items being launched such as the vulnerability scanner and I can't say how much what you are sending affects the timings.
Sorry I can't be any more specific than this. Definitely play about with the settings. If your core is reasonably powerful try increasing the number processed at the same time (240 is the max). If this doesn't make much of a difference, then start looking at the other connection options.
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
Yes, server is very powerful. HP DL380, 8 cores, 64 Gig, 10 Gig NIC. I was going to up the processed to 128 and just use UDP for discovery, since TCP is tired to HTTP. These timeouts can take 20 seconds or more. If a lot of target devices don't respond to the TCP connection, your job will take a while before it can start.
Thank you for the reply. Have a great holiday season.