You could trick landesk into excepting the result of the batch script by forcing a zero code returned - set errorlevel = 0 at the end of your batch script, but if you do this, you could be avoiding the real problem - Why is your batch script throwing a code 1 to come back in the first place? You might want to post your batch code here so folks can better help you on it.
So it looks like you're trying to set the password of a local user account. If this is the case, you're going to probably want to run this command manually on a machine and try and find out what that code 1 error is all about. Chances are something's going wrong with the command. If the command is successful, then the batch should be returning a '0' value not a 1. I'm seeing a code 2 if i try to use a 123456 password since it doesn't meet minimum password requirements on my system, but you're getting a code 1, so that must be something else. I also got a code 2 trying to set a password to a non-existing user, so i changed the user to a local account that did exist and a password that met minimum requirements, and it worked fine, and returned '0' value.
Try adding this line to the end of your batch and run it manually on the machine where you get the code 1 returned in landesk, and see if you get the same code echoed when you run it manually:
BTW... i don't think you really need the "cd" line in your batch, unless your system32 directory is not in the path environment variable.
Lets work on the theory you are trying to change passwords via a command prompt, I've done it like this in the past using a script like the one below, if not you can see how this script works using the cmd /c switch
REMCOPY0=%DTMDIR%\ldlogon\hidedos.exe, c:\software\hidedos.exe, TOREMOTE
; copies "hidedos.exe" to the client's c:\software folder
REMEXEC1=c:\software\hidedos.exe cmd /c "net user administrator newpassword"
; runs command to change local administrator password to newpassword hiding the dos shell from the user so they don't see it
I'm not sure where it sits by default maybe I copoed it to the ldlogon folder. Either way here is a link to another discussion and you will notice someone has attached a copy of the hidedos.zip to the response
I never thought to ask, I don't use it personally as I found we ended up with 5 variants of the password and engineers ended up going through them to find out which one was valid. I use the batch file method because once it's been changed I get it to write a numeric value into the registry say pass=1 which I use landesk inventory scan to query and then I have a column in the management console to view which password the machine is set to and which ones need changing
Change them all to one password with LANDeks and then you can roll with quarterly password changes (depends on how secure you want things).
Right click on a machine and select "Manage local users and groups" and then (in the new window) select Schedule from the icon on the tool bar at the top. Select a username to change the password and enter the new password then click Schedule. It's a normal distribution job from there.
As for batch files I usually test them beforehand to make sure there are no other propmts coming up in the DOS box. Is the user "test1" already on the machine you tested on? If not that will be yur problem and you need to do a net user username password /add command.
Your right it is nice and simple to do it through landesk but you can't tell which ones have been done and which ones haven't. It can take me months to get them all up to a single password with the laptops working remotely and machines switched off. Now if the inventory stored an entry saying user x password last set I'd definatley go down the landesk route.
There are different ways to assess which machines have been done. For one you can look at the scheduled task (post-fix the name with dates) to see if it has completed successfully or you can right click on a machine and see which "Scheduled task or policies" it has run (successful and unsuccessful).
Something else you might want to consider is having as part of your base build is a vbscript that can be run periodically (once a day/week/month?) by the local scheduler that populates a registry key with the info held by the Windows pwdLastSet attribute, then you can get this in to LANDesk very easily and with little admin overhead once set up. You can see the last date it was set using net user <username> then hit return and it gives you a heap of stuff (password last set date being one of them).
This also all depends on how often you are changing passwords. If it's once every 6 months then you could just set the job to repeat daily this could reduce you down to two possible password combinations.
Hope this helps.
Although the failed message told you the Deployment failed, I think the batch file is already downloaded to below path in the client PC.
C:\Program Files\LANDesk\LDClient\sdmcache\ ...
the factor may let it failed is came from the permission of access C:\windows\system32.
Try run this package via Local System Account rather than Logon user account.
Or your test1 account hv no permission to access C:\Windows\System32
I am getting a similar issue.
Processing package : U0240_Deploy_Best
Thu, 22 Sep 2011 15:28:32 File (\\nyutl002\pkg\Pre_inst.bat) is not in cache
Thu, 22 Sep 2011 15:28:34 Performing TCP connection with a timeout of -1 milliseconds
Thu, 22 Sep 2011 15:28:36 ILdDownloading file to C:\Program Files\LANDesk\LDClient\sdmcache\ldlogon\FileLists\taskmanifest.NYUTL027.154.96.ini, attempt 0
Thu, 22 Sep 2011 15:28:37 ILdDownloadFile returned 0
Thu, 22 Sep 2011 15:28:37
Downloading file \\nyutl002\pkg\Pre_inst.bat (kDDKJhYav/dy2uydaF6LuA==, 5)
Thu, 22 Sep 2011 15:28:37 Downloading file 1 of 1 from '\\nyutl002\pkg\Pre_inst.bat'
Thu, 22 Sep 2011 15:28:37 processing of package is complete, result 229392397 (0x0dac400d - code 16397)
Thu, 22 Sep 2011 15:28:38 File (\\nyutl002\pkg\Pre_inst.bat) is cached locally
Thu, 22 Sep 2011 15:29:01 Deferral result indicates that we should not continue (8dac400e)
Thu, 22 Sep 2011 15:29:01 processing of package is complete, result -1918091250 (0x8dac400e - code 16398)
My batch is a simple MKDIR command.
IF EXIST "C:\Windows\System32\config\systemprofile\desktop" Exit ELSE (MD "C:\Windows\System32\config\systemprofile\desktop")
I see the folder getting created but I noticed the time it takes to run. It's acting as if it doesn't "exit".
Thanks in advance.