Description:
The idea of this document is a resource for what to look for when an Software Distribution job fails. It's intent is to help anyone using the LDMS product narrow down the cause of a failed Software distribution job. This document is not intended to cover high level troubleshooting (I.E. using Xtrace and Packet captures).
Assumption:
This document is assuming that the Software Distribution job has actually attempted to run on a system. This document is not going to cover scenarios or problems that may occur with "Scheduling" a Software Distribution job. Troubleshooting the "Global Scheduler" is an entirely different topic.
Understanding how Software distribution tasks run:
The first and worst assumption that is always made is the following: "The software installs fine if I browse to the location and run it manually". This is the biggest misconception that almost everyone makes when trying to diagnose a Software Distribution task. When a task is run using this method, it is ran as the logged in user, or if desired the "Run as" option is selected and it runs as a specific user. By default LANDesk runs it's tasks using "LOCAL SYSTEM".
The only way that a Software distribution job should ever be tested is trying the run them as " LOCAL SYSTEM". The following document will walk you through testing an application as "LOCAL SYSTEM". http://community.landesk.com/support/docs/DOC-2316
Once you have brought up the "LOCAL SYSTEM" CMD prompt do the following. Use the "NET USE" command to map a drive to the software location. Make sure that when the application is selected the switches that may have been added when creating the task are used. (For Example: msoffice.exe /q)
If the application still fails
- The application should always be tested on a multiple systems. It is possible that a single test system may have a problem.
- Make sure "LOCAL SYSTEM" has the appropriate rights to the share.
- If the same failure occurs on all test systems a call should be made to the vendor of the application that you are trying to deploy. The vendor is always going to have the most insight as to why their applications fail to install. It could be something as simple as a switch that cannot be passed, or something as unlikely as certain operating system patches have to be applied first.
- Before any Software Distribution packages are created using LDMS it should be tested using the above method first. Verify all is working as expected.
I can now run the software as "LOCAL SYSTEM"
What should I check on the client side:
The sdclient_taskXXX.log in the ldclient\data folder. This log contains almost everything that should be know about the task.
Open this log and scroll to the bottom. If the job is failing something like this will be seen:
Fri, 23 Jan 2009 12:40:47 .\AdditionalFiles.cpp(62): (8DAC4026): Failed to download file http://LANDesk.Gateway@10.4.42.98/ldlogon/FileLists/taskmanifest.WLUDEV071119.154.2303.ini : (80070002)
Fri, 23 Jan 2009 12:40:47 processing of package is complete, result -1918091226 (0x8dac4026 - code 16422)
According to this log the taskmanifest file is not being downloaded to ldclient\sdmcache.
What to do with this information:
At this point we have an failed result code that is highlighted in red. You should go to http://community.landesk.comand search for what is highlighted in red. I would first put both together. If I get nothing search for the results separately. -1918091226 first. If I get no hits search for (0x8dac4026 - code 16422). These questions are usually answered in the community. If not, you know what to talk to the support tech about.
Downloaded http://ci-ldms/Ldpackages/SWDistribution/JR142_18b/Ldms/Onefile/JR142_18b.exe did not match the hash, expected o23uEj6jKNWh+0pDt9oK1g== actual JE1ajAIxHFHUTV11Hs73fQ==
Mon, 15 Dec 2008 11:55:17 .\AdditionalFiles.cpp(227): (8DAC4027): Failed to download and hash all additional files.
According to this log there is a problem with hashing of files. There is already a great document on this issue. http://community.landesk.com/support/docs/DOC-8224.
Also searching the results in http://community.landesk.com is always a good thing to try.
Note: No matter the error message seen in the console. It is always best to review the sdclient_taskXXX.log first.
What if I know my task installed successfully, but the status on the core server is not reflecting a success.
There are a couple of reasons that can cause this issue:
1. Return Codes- Some vendors will send back a return code that is a non "0" for a success. LANDesk interprets anything that is not a "0" return code as a failure. This is common in applications like Office 2007. In the case that a vendor goes away from the standards and uses non "0" return codes as success.
In LDMS 9.0 or newer, the Return Code Template that is associated with the package can be changed to include this non-zero exit code as a successful exit code http://community.landesk.com/support/docs/DOC-7489
In 8.8 and older versions, the resolution is to use a batch file. See article: http://community.landesk.com/support/docs/DOC-2320
2. Client is simply not sending the status back to the core- This can be narrowed down by looking at the following article. http://community.landesk.com/support/docs/DOC-2919
What can be done to make sure I limit the possibilities that LANDesk is going to be the reason a job fails.
1. Make sure your core & clients are on the latest service pack.
2. Make sure that your clients have the latest version of lddwnld.dll, and tmcclnt.dll.
3. Configure the Core Server and all shares the software packages are stored on to be Preferred Servers. This is easily configured on the Core server under Tools | Distribution | Content Replication/Preferred Servers. An IP range does not have to be configured. See Article: http://community.landesk.com/support/docs/DOC-1385
NOTE: See the following for more information on Troubleshooting Policies: http://community.landesk.com/support/docs/DOC-3245