Can you run the batch file as LocalSystem and have it succeed? If you are dealing with something on a share that is often the problem. I would launch a command line as LocalSystem (from the LDClient folder you can do localsch.exe /exe=cmd on XP, Vista that won't work so nicely for). At that point I would run each line in the batch file individually and see if/where you don't get what you expect to see.
The status that gets returned in LANDesk is going to be the status of the batch file exiting (most likely it exits just fine, even if an individual line failed).
In addition to what Mach6 stated, I'm curious as to why not just deploy the SWD/Package Builder Package and dump the batch file? If there is any logic in the batch file it can be relicated in the SWD/Package Builder Package.
Okay guys, first, the reason I haven't used the SWD Package over the batch file package is because 1) I didn't want to have to download all the additional files onto the machine and 2) I hadn't really been taught to use the SWD Packge option. What advtange does this option have over the remaining packages?
Also, in regards to the batch file I do have. I was comparing the log results from a similar batch files that I've run and that has worked.
Notice below the first batch file (in red) is calling the file from the network share. This is the one that's not working. The other two that work perfectly fine are calling the batch file from the sdmcache. I'm not sure why this is happening but the batch file setups are completely identical. The only difference is the actual batch file. All these batch files are one liners with some switches.
Wed, 20 May 2009 15:58:28 Bat file output :
C:\Program Files\LANDesk\LDClient>call "\\rtpnas02\Apps\ClientApps\DVD Player\Power dvd\powerdvd.bat"
Wed, 20 May 2009 09:19:34 Bat file output :
C:\Program Files\LANDesk\LDClient\sdmcache\apps\clientapps\Microsoft Product\MSN Live Messenger>call "WLM2009.bat"
Wed, 20 May 2009 09:17:53 Bat file output :
C:\Program Files\LANDesk\LDClient\sdmcache\apps\clientapps\cgnet>call "silent.bat"
Let me know what you guys think.
That's 99% likely where you're stuck at.
Here's what happens (for "normal" users).
LANDesk checks "Do I have local admin rights?" - when the answer is "yes" we continue running in the existing user context.
Now, most commonly, your average user will NOT have local admin rights, and as a result, we will relaunch in LOCAL SYSTEM context. Now depending on how you set up the UNC share, this is the problem right there.
One of the possibilities is to add the "Domain Computers" account to have access rights to the share (that's how LOCAL SYSTEM would get in), but alternatively, you could just add the respective files as ADDITIONAL files of your batch file, that way you don't need to do a copy, and have got the more reliable LD distribution techs (including peer download) ... much easier to then execute the files when they're in the local SDMCACHE .
LANDesk EMEA Technical Lead
What I don't understand though is why two of these batch files work just fine. They are on the same exact share, and I'm running them on a test computer with administrator rights.
Also, I agree it's easier to distribute the files when they are in the SDMCACHE but some of the installations have too many additional files. For Adobe Reader there is a 100MB .cab file that it needs to pull over resulting in a download that takes a while. That's why I like the batch file method.
If the other two calls are on the exact same share, then you're probably looking at a file-level problem. You may want to run FILEMON on the server in question and just confirm that you're getting a file-level deny. Filemon on the share (and filtering for errors/deny's) should confirm this hopefully .
In other things, you can re-package stuff as well. There's the "simple yet effective" and the "bells and whistles, but more complicated" method, depending on what you're doing.
This is PARTICULARLY good (as it happens) with batch-files.
What you do, is you throw the entirety of Adobe into a ZIP-file (or your preferred compression tool), and add the single ZIP-file as an additional file to the package. The batch can then simply decompress the files, and then run the install locally.
The "bells and whistles" method is usually used for MSI's, and that is essentially including all of the other files (sometimes even the MST) in the MSI itself, makinga singular big file.
This "single package" approach (be it ZIP or MSI) has many benefits, on account of far fewer overhead in both time and resources when compared to a massive file-list (Office being a particularly popular subject here, with it's 1,000's of files).
As an addendum - this "single file" approach also has the benefit that you can easily use HTTP-shares, which throws away a heck of a lot of access-issues which NT will throw at you (I've seen "fun" stuff like this before where one file for some obscure reason would not be giving NTFS rights to domain computers to be copied, and other such fun stuff).
LANDesk EMEA Technical Lead.
Message was edited by: Paul Hoffmann
Way up at the beginning I said essentially what Paul Hoffman is saying (in less detail about the single file options for packages). That is, that you probably have UNC Sharing permissions problems. I included a simple test to run the package more or less how LANDesk would. Have you tried it? It will take about 10 - 12 minutes to do the first time you ever try it (assuming you have to walk 30 feet from the computer you're reading the instructions on to the computer you're testing on, otherwise it will take about 4 minutes, even the first time). After that it will take 2 - 3 minutes any time you need to test it in the future.
Have you done the test? If not, is there a reason why? As Paul said, 99% of the time a problem like this is related to permissions with the UNC Share.