So I would always create a log file for application installs and save that to a consistent location on the client (easy on MSIs different/difficult for EXEs). This will allow you to troubleshoot installs. This way you can evaluate the log file to see if it was successfully or failed and compare the results with what LANDesk says. It will also sometimes show the actual return code of the Installer so you can map it as a failure in LANDesk.
Do you have any MCPs installed on your SP2? There are a lot of fixes for software distribution. Evaluate and TEST the MCPs before deploying, or I would suggest evaluating SP3.
Rather than checking the room you can use the Inventory to see if the application was installed, saves some leg work._____________________________________________________________Please consider voting for these ERs:Provide Better Pre/Post LDMS Patch/Sp/.0 Information To The CommunityCumlative Patch List for LANDesk ProductsQuery Builder ImportProvide bulk client deletions without carpal tunnel syndrome.Core Synchronization Allow Mirror functionality from Master Core
1 of 1 people found this helpful
One issue I've found with using EXE packages is that the executable may not report the error code back to LANDesk. This is independent of LANDesk and is completely on the writers of the EXE. If the EXE executes all of it's processes properly, it should report back to LANDesk with a successful code. I have seen this where the executable has internal processes to document the error-perhaps outputting the error to a log file-and then completes its work. The writing of the error to the log--from the perspective of the EXE--is successful and the EXE completes its processes and relays that back to LANDesk. You need the EXE to output the error to LANDesk when completed and then you can capture the error message\number so that you can remap the status code in LANDesk as ZMan suggests.
I would second the suggestion to check all updates to both the core and the client. Nothing is 100%, but the rate of false positives you are reporting is unusual, especially for something as simple as Adobe Reader. That should install like clockwork.
Two things we do to help us with deployments and reporting.
1. Every application we deploy we include a batch file, vbscript, or AutoIt script to write the name of the applications and date it was deployed to the registry upon a successful return code. Then we pull that into custom data for reporting.
2. For time-sensitive deployments we also force and inventory scan as the last thing before exiting the script.
Thank you all for the responses i have had to this post.
i am going to go through and do some more testing and see if it is down to EXE by replacing the Adobe Reader EXE with an MSI. and see how that goes over a period of a few weeks to start with.
You can always go to Adobe's website, register for an enterprise license (it is free) and you can then download the msi versions of all their "free" products - Flash, Shockwave, Reader etc.