Unfortunately things are not quite as simple as you'd like them to be - not everything is our fault, no matter how much simpler it would make things.
Return-code templates have been brought into the product specifically to deal with the sort of "fun" that you're running into. That's not a complete solution - because it requires people to actually use them & fill them out - but the "worst" problem is that error codes are nowhere near as uniform / standardised as people expect them to be.
Even among MSI's - I've had a quick google for one of my "pet favourite" MSI return codes - 1603 - and here's a little bit of reading material for you to indicate the sorts of fun that thing causes (links to 3rd party sites & such):
By and large - "long story short" is it all amounts to "failed to install", the details of which end up being much a "fun" merry-chase around as to what on earth could possibly be the actual cause (which is one of the reasons why I *ALWAYS* advise that people use the MSI logging option when installing MSI packages).
But ... there's more!
Return codes are inconsistent across different installers - and sometimes versions. And not all non-0 return codes translate into a "failed' type - one of the most common representatives of that camp is MSI code 3010 (Reboot require to complete install). And that's "just" MSI's.
It gets a lot more "fun" with non MSI-based installs, or wrapped packages (a particularly "fond" memory being an exe-based installer wrapped in an MSI, wrapped in an EXE, wrapped in an MSI - calling command-line switches that don't exist and 0 documentation for the entire thing), as with a multi-tiered installer like that, it becomes a bit of a lottery as to which layer actually threw the error code & what it actually means (most of what we can do is report back the numeric result & try to make sense of it).
As an aside, LD 9.6 (and onward) has gotten a lot tighter around the capture & reporting of return codes - so you will want to pay attention to that when moving to LD 2016 & re-test your packages (which should be part of upgrade testing anyway, but the improved error returning has caught some folks out, so I'm highlighting it).
And then you have script-files & such things, which (if written well) can have consistent albeit custom return codes, but that is not necessarily the case (and often isn't).
So - what to make of all this then?
Software installs can go wrong in myriads of ways - and usually the 'most useful' thing we get handed is a return code that we try & report up & be somewhat helpful about in as far as possible. As indicated above, even something as apparently standard as MSI return codes very quickly prove not to be terribly standardised / consistent.
It's why we've introduced Return Code Templates. It's why we introduced things such as the "Diagnostics" options with 9.6 - so that you can have a look at log-files on a client without having to remote control it (which - by the way - once you start using, you'll get to love that feature for its convenience factor). We can generally only help you along with the bread-crumb trail (and I'd like to think it's something we do).
The real problem is that we don't own all those software packages - they're down to the vendors. And there's some good packages out there, and there's an abundance of atrocious packages out there. Both commercial and re-packaged ones (hence my usual suggestion about having a GOOD professional repackager) ... any IT guy can try their hand at re-packaging, but there's quite a bit to it, if you want it done well.
Oh and - as an final note ... plenty of Soft Dist troubleshooting information to be found here:
- Community space for Software Distribution
... and incidentally, moving this thread over to the Software Distribution space, since it's somewhat specific to that subject.
I get that you can get frustrated with that aspect of the job - most (if not all) of us will do at some point when having fun with those "special sauce" packages / device combinations & things don't seem go your way. But not all of it is our fault .
Between things like return code templates, the diagnostics tool - we're still continuing to come up with ways to "do this better". And if you've got a suggestion, you can enter it as an enhancement request - if it's a great / popular idea, it'll become a thing.
But there isn't a magic bullet to solve complex IT tasks. We can empower you, we can support you - but there isn't a magic button that will "work all the time" ... it's why so many of us have a job doing what we do. Because of the nigh infinite variations of things (even in well controlled environments) and eventually 'something' can go wrong.
I hope that this helps bring a bit of perspective.
Thank you for your answer Paul, but unfortunately, that is not something I can take back to my boss when he asks "what do these results mean." He would boil down your statements to "I don't know", and that makes me as the local expert look bad, and ultimately makes LD look bad in his eyes too for not having something more useful.
I know it is not the job of LANDESK to interpret every return code, which is why I am reaching out to the community at large to see if anyone else has encountered them, and if so, what they might have done to solve the code. I refuse to believe I am the only one who has seen these, and I refuse to believe that someone out there hasn't documented a possible solution or explanation. That documentation just hasn't made its way to the community sight, and I am hoping to draw it out. If we as a community can come up with "I saw this, and did A, B, and C to fix it", we can compile all of those into a useful guide to help fellow admins. LANDESK does not need to come up with the solutions, but LANDESK can help collect and organize the solutions their customers came up with.
We started a similar guide internally, documenting everything we happen to find and if we have solutions or suggestions to pass on to our local LD admins to help them troubleshoot. Unfortunately, I can only explain so much, and would like help from my fellow experts that have seen and done more that I have.
So community, I ask again, has anyone encountered the return codes I posted, and if so, what have you done to rectify the situation?
Gotcha - all makes sense and I don't disagree.
Have no problems at all about a section around no talkers and return codes. Will try to get some Soft Dist'y eyes on this as well to bounce a few ideas around on how to do so best (or better at any rate).
Key difficulties as I see them are as follows (not criticising - just thinking out loud):
1 - in my experience the relevance of return codes is usually closely tied to specific packages - so a lot of it comes down to "this applies mainly/only to Office / Adobe / whatever installs".
2 - as soon as people customise installs and/or repackage them (often a necessity) normal rules may not apply. It's why I *REALLY* started to appreciate capable, professional packaging folks.
Sure - "any IT folk" can try their hand at (re-)packaging if needed but there is a big difference between that and being able to do so competently.
3 - As indicated previously, exe-based installers can be even more "random" / uniquely tied to their specific install.
Will have a ponder on this one :).
Good discussion post and thanks Paul for chiming in on this thread. The better understand how to address any return code it will be beneficial to know where it originates from. Generally a hex value or a positive or negative decimal string value is associated the the word value returned when the application exits. The hex however will contain a facility code which would lead us in the proper direction in understanding what these values is associated to.
We've compiled a list of return codes and they are contained in the following community article: https://community.landesk.com/docs/DOC-27397 Most importantly, review the pdf in the article.