You may want to read up on task queueing before you start going on a rampage. Software Distribution is doing what it is supposed to do which wait its turn to process whatever it is trying to do. If another instance of sdclient, vulscan, provisioning are running then it will wait its turn. Fyi, you can disable task queueing on the distribution package so that the task will just fail instead of queue itself up.
I would not be quick to blame the product if you are not reading up on these functionalities or your environment is not setup correctly. LANDesk is like anything else, configure it correctly and it will work great, configure it poorly and it will perform poorly.
even with the standard "Push" delivery method? The LD help files define the Push method as:
- Push: The packages may be multicast out to the managed devices. The core server then initiates package installation at the managed devices.
I can't find any documentation on the Push method being queued up.
Even if Push will que the SD job, i have waited on the que to finish for at least three days since setting up the SD task. Even if the machine had 5 tasks to complete before getting to my SD job, why would it take three days to finish those tasks? In fact, while checking on the scheduled tasks and policies for one of the machines in question, i noticed that all of them say "waiting."
anyway, thanks for the help.
Sounds like you have a hung task on the client (a package that is crapped up). Think of it as a truck that is jack knifed in the middle of the highway and no other cars can get by (cars are you distribution jobs). You will need to clear the queue. Support has a script that will do that. Normally I try and find the root cause as why the installation of a package hung, before wiping out the hung job (killing sdclient).
Here is a prime example of my Software Distribution frustration:
This task is being pushed out to the the same model computer, with the same image, with the same LD agent installed, on the same subnet. Why do i have so many different responses from the client? Even the ones that completed still have other tasks just "waiting." When are those tasks going to get done?
See attached .jpg.
LDtaskerror.jpg 1.0 MB
How do i stop/reset the task queue process on the client? if i disable the task queue (in my distribution package) it says that the installation will fail if there is already a task queued? and if the tasks that are already queued up never get finished then nothing works.
Just so you guys (or I) don't think me crazy, here's further evidence that Landesk hates my guts.
Explain this to me: I tried to simply multicast out the file and the error says that either the machine isn't on (not true because i was remote controlling it) or multicast isn't installed (also not true as evidenced in inventory).
How am i even supposed to figure out what's going on here with the crappy error codes and messages that the client returns to the console?
And to Zman's point, why should i have to manually restart SDclient.exe? Why can't it just work? Why can't any of this just work without me having to implement some manual work-around?
See attached file
LDmulticastError.jpg 1.3 MB
sdclient.exe can hang for various reasons. One big reason is a bad package, meaning that it wasn't truly silent and is waiting for some input. It will never get this input since, by default, it is running under the SYSTEM account. Not saying that is what you are experiencing but possible. One easy way to clean up the queue that has worked for me in the past was to create a Managed Script that cleans out the queue and then try the push again. My script looks like this
REMEXEC0=cmd /c net stop "Intel Local Scheduler Service"
REMEXEC01=cmd /c taskkill /F /IM sdclient.exe /T
REMEXEC04=cmd /c taskkill /F /IM taskqueue.exe /T
REMEXEC05=cmd /c net start "Intel Local Scheduler Service"
REMEXEC06=cmd /c del /f /q "%LDMS_CLIENT_DIR%\sdclient.tasks.xml"
;REMEXEC07=cmd /c del /f /q "%LDMS_CLIENT_DIR%\..\Shared Files\cbaroot\alert\queue\internal*.xml"
REMEXEC08=cmd /c net stop "LANDesk Policy Invoker"
REMEXEC10=cmd /c "%LDMS_CLIENT_DIR%\DeleteTaskQueue.exe"
REMEXEC11=cmd /c net start "LANDesk Policy Invoker"
Managed scripts don't get affected by the queue since custjob.exe does not care. Others can chime in with different scripts or better methods but this is what has worked for me.
For your multicast error... Do yuo have any firewall active on that PC? Of course it can be that RC is allowed, but MC is blocked...
OK, first thing - You Aren't Mad. You're angry and frustrated, but not mad. LANDesk is obviously not working for you right now.
Second thing though is that something has caused it to go this way and unless that gets fixed then trying again and again is just going to pile up the pain you are having and make it unbearable, so no matter how hard it is you have to overcome the frustration and go back to first principles.
The first principle I'd like to visit is that targeted multicast works. I know that because I just sent XPSP3 out as a test to machines across multiple subnets and it did what it was meant to. Not trying to rub this in your face or say I don't believe it didn't work for you just that the issue is that it isn't working for you for some reason, it should, and that is why we need to take this right back.
If you aren't on v9 SP3, then get there. Best place to start from with one really big caveat, if you've done a lot with HII and or in a mixed WinXP and Win7 encironment then you might have issues with the new HII model, so watch out for that on the community. A patch is available to those that request it but I don't think the work is complete yet (quick note, LANDesk is working as designed, driver detection is broken because vendors seem to be lazy when writing their .inf files). I say go there because it gives you a solid base to work from and a reason to nuke/re-install every client and attempt to clear up whatever it is that is causing your issues.
Even without SP3 you could ignore every other machine for the time being and get yourself a nice sample group and clean them up. Get a new client configuration setup, remove the old client config off those machines and get your new one on there. Once you've done that, then just test the functionality to prove to yourself that it works. Get confident in the base functionality rather than throwing more jobs at systems that aren't doing what you expected. Do what you can to avoid using any non-pristine clients even as subnet reps.
I know this is probably teaching you to suck eggs, but this is the reverse of 'if it ain't broke don't fix it' - it is broke, so you need to fix it and tempting though it is to hit it with something blunt and heavy that probably won't do anything except make you feel a little less frustrated in the short term.
There is every likelihood that something in your environment is causing the system to become unhappy, networks, conflicting software, the users themselves, but until you get basics working then you're looking for a needle in a haystack.
LANDesk is not perfect by a long stretch. It has some fantastic ways of achieving things and more ways of doing them than you can shake a stick at but what makes it work for you is probably different to what makes it work for other people. Also, every product has their issues; I know that because I replace them with LANDesk because of those people being frustrated and I do everything I can to prevent those people doing the same things that led to the other product failing.
Rebuilding a system from first principles (not necessarily a clean re-install, rather a reset of patch levels and mind sets) can take time but it can be worthwhile. It is one of the main ways I've taken other organisations from the brink of throwing the whole thing out to the point where they wouldn't part with it for the world.
If ultimately the product cannot cope in your environment then that is one thing, but if the application of time and focus can bring it back on track is that something you'd be willing to do?
Calm, deep breaths, focus, use the force, whatever it is you need to do in order to bring this back on track.
LANDesk Silver ESP
The One-Stop Shop for LANDesk Enhancements
Thanks Mark.....always the calming voice. You have helped me many times before and appreciate it. You're right....i'm not mad. Just frustrated. I was under a little pressure to get this software installed and it wasn't working at the time. And i will say that i did not uninstall the old agents (nor did i create brand new ones) before i updated them. and i was also frustrated because i had just installed SP3 and was expecting it to work flawlessly. I've been in IT long enough to know i should make sure everything is functioning (as you say) on first principles before i start saying thing suck.
so im going to try building a new agent and putting it on a clean machine and try the software dist again.
thanks for convincing me not to smash my core to bits.
Actually Frank i have seen the local firewall block out LD for some reason but i didn't check that this time. Will take a look.
Good luck jeff.
Also, if it does get to the smashing up point, have a variety of tools to hand as well as strong boots. More satisfying if you have different ways to achieve the objective.
LANDesk Silver ESP
The One-Stop Shop for LANDesk Enhancements
Hey LANDesk Wizard,
Was wanting to give your script a try and I was looking over it and just making sure it will work and i had a quick question: deletetaskqueue.exe in line 9...is that something you created or is that something on the LD core somewhere? I am not finding the %DTMDIR% variable on my core anywhere....
i actually tried to run it and it fails at copying deletetaskqueue.exe to the client...
i was right to begin with.....Landesk Software Distribution does NOT work. and yes, it still sucks.
i give up.