You'll need to go through the package / SDCLIENT logs (and probably enable debug-logging) - to see what's going on.
Chances are, one of the packages is giving you a non-0 return code (which may still be fine, depending on the details, you may just need to ammend the relevant return code template to "teach" LANDesk that "return code X means - I installed fine").
Here's info on how to enable debug logging - How to enable Xtrace Diagnostic Logging .
Also, check out - How to quickly troubleshoot a Software Distribution job - as a primer.
Logs that'll be interesting to look at will probably be...
- (...)\LDCLIENT\DATA\sdclient_task####.log - based on the task ID of your bundle/task - so something like "sdclient_task14.log" for instance
You generally should only need to check "from the bottom up" as it were, since you're probably looking at exit codes from the package(-s) in the first place.
... and go from there?
Thank you for the reply.
I looked at the SDXXX.log file and I did see a -3 result code got generated. I think you are spot on with the return code template. I remember that I did add this return code to our old LANDesk 9.5 system. Sometimes we forget what we did to get where were are now.
Thanks for the help.
No problem - happy to help.
I'd suggest standardising / establishing package documentation for reasons like this. You get weird packets / installs & have to come up with "interesting" workarounds at times.
Documenting those things with the package(s) tends to reduce such trip-ups (I say "reduce" because I've yet to run into a setup that eliminates such things completely).
We are and have been looking at a change management document or a complete change management system as well. This would definitely reduce the upgrade pains.