You could use a batch file and conditionally exit on an error (EXIT /B 277). Jared wrote a great tech doc on this About Batch File Distribution Packages
You could also use a language such as vbscript (YAK) or Autoitscript to exit conditionally. If you are using straight LANDesk scripts REMEXEC0= it does not allow for conditional branching.
The question you have to address is what is failure? If you are running an EXE or internal or external command it should return an errorlevel or return code. Just test for a failing return code and exit. If you post your script we may be able to help you further...
Yeah I understand what your getting at. I hate having to go from built in to another script type just leads to another potential point of failure. I know the problems ins't the landesk script its simply our network. We have a HUGE infrastructure and the left hand doesn't know what the right hand (or the left knee or any other body part to be quite blunt) is doing. Multiple subnets, 2 distictly seperate networks that are kinda half merged but not functioning right, broken DNS, DFS file issues, and bad routing are just some of what is all going on.
I know about reading the logs to get the exit codes and I do that myself when I am running it the problem is we hvae a bunch of users who don't know much about LanDesk and I am trying to dummy it down a bit for them. Also I am not admin in the LanDesk server at all I have limited abilities even though I have attended the LanDesk training.
The LanDesk scripting needs to become more robust in my opinion. It seems so limited that I am constantly pointing towards other solutions like vbs files.
I think LANDesk purposely made the scripting very lightweight. The way I look at it:
Vbscript (Almost never)
Full Blown Packagers (Wise/Admin Studio)
This is the order in which I approach a scripting job. All in all LANdesk offers a lot of flexibility and options. However, with flexibility and options comes more decisions. Options 1 and 3 are just there and LANDesk is really not enhancing them. That is why in our shop it is either a simply batch file or Autoitscript. I think if you spend the time and effort to go outside the basic LANDesk scripts it will be very rewarding, but I hear ya.... I just bought this bright shiny new package and I have to learn something else outside the box.
Really the order may be different for ever user. The order should be based on how well you know a product and how well the product works.
For example, I know batch files pretty well.
Batch Files (These are not outdated, in fact, batch files are more valid and powerful today than they were in the DOS days.)
Vbscript (Move to first if you know VBScript)
Full Blown Packagers (Wise/Admin Studio)
LANDesk Scripting (I pretty much stopped using thisin favor of a distribution package for batch files, even though I know it well; because, if it can be done here, it can be probably be done better in a batch file. The one feature it has that makes it best for the Inventory Scanner script, is that it can do different things depending on the platform. So it can properly have an inventory scan run on all platforms.)
Package Builder (Almost never use this anymore unless I want to make a registry key change to all user registries in xp/2000. It doesn't even work with Vista.)
Autoitscript (Never used it by I hear great things. I am sure if some one was good at it, they could put this as #1.)
I hope to become a VBscript master eventually too and once I do, maybe that will move to #1.
Actually any number of things could be #1 for any number of administrators. If you know perl, php, bash, you could install perl, php, cygwin, on your end workstations and go to town scripting the way you want to. Since we don't have Distribution Packages for those, you could call them with one of the distribution packages we have without having to learn a new scripting language.
Powershell is very powerfull as well. This would require a hot fix to be pushed over to the clients though. I started playing with it a few weeks ago.
I too think the order can vary greatly. I used to use batch files and whatnot but alot of the things I deal with have no batch file roots or command prompt equivilents without getting extra "add-on" exe's. Also when using batch files I was finding I had to call to other things that I didn't want to have to call upon. Also alot of manipulation you just can't do with batch files that you can with VBscript.
VBScript defintiely has its limiations (as does any lanuguage I have encountered) but it does seem to be robust and the fact that all of our clients (windows 2000, XP, and VISTA) natively support it.
If I were to break it down I do it this way -
1) LanDesk scripting (you have to use this to get your pushes deployed)
2) command line installs with answer files and good command line switches
4) Package builder
We are not allowed to use Autoit in this environment though I use it at home and love it and we have not had any ability to use any packager outside of Package Builder.
I don't want this thread to get into a my scripting language is better than yours....However, like a lot of you older members, I've been around for sometime and have used probably every type of scripting (winbatch, batch, vbscript, perl, Builder in the DOS days, Autoitscript, etc...). I feel compelled to give props to Autoitscript. It is a mature, well updated and supported, great tool. We have used it for a couple of years without any issues. It is very easy to use and extensible. What would take a couple of hundred of lines of VBcode takes about 50 in Autoitscript. Also I like programs that are not hooked into the OS (Powershell/VBscript) - just my opinion. Jan (JANc) has written some cool Autoitscript stuff. We wrote an entire OSD provision system before Provisioning. Take a look.
Also the order I stated was just my order.......Like everyone said it will vary greatly based on numerous items.
I got 100 on vbscript and auto It!!! haha
Zman - I've been looking into Auto It i did some basic scripts although I would like to dive into it a bit more. Do you know were I could find some good docs?
Any new language is daunting - verbal or computer based. The best docs are the help files. They are very well written and contain examples for each function in the help file and an open script button, that opens the example in scite so you can run it. Here are some good links:
That should hold you for a while. There are a lot of UDFs that extend the functionality. Example, 8.8 uses SqLite for the local DB (they tool all the apm cache registry entries and placed them in a local SQlite DB). This is nice, but you can't troubleshoot policies by browsing the registry anymore. Autoitscript has builtin support for SqLite DBs.
Some hints. Take it slow - small bites. Download some real world examples from the forums and open them up and investigate. Pick a small project and go for it and have fun
Thanks alot for all of the information on Auto It. Im deff going to take your advice and dive into a project. I believe thats the best way to learn.
Would all of Auto It's functions run in the WINPE environment? I wrote a small search and replace script and that worked fine but Im wondering if some of the more in depth scripts would work. Im thinking yes as auto it complies everything into an exe.
There are many Winpe scripts on the forums - ImageX GUI wrappers, etc... I would venture to guess that there are some functions that will gag under Winpe and BartPe since they both includes only a subset of the Windows Vista
Win32 application programming interfaces (APIs), including I/O (disk
and network) and core Win32 APIs. Applications that require any of the
following Win32 APIs will not run in Windows PE: access control,
NetShow Theater Administration, OpenGL, power options, printing and
print spooler, still image, tape backup, terminal services, user
profile, Windows station and desktop, Windows multimedia, and the
Windows shell. Hooked that from technet.
It is a very robust scripting environment for Winpe 1/2 and BartsPe.
Some PE stuff
ryse asked: "Would all of Auto It's functions run in the WINPE environment?"
If you complile the scripts then yes. We have a series of pretty customised OSD scripts and I added alot of functions that work in Win PE by passing inventory information to them in the OSD script. They work a treat and havent run into any problems yet!
I agree with CraigRigby we have had great success under WInpe, however, there are several posts on the autoitscript forum that indicate issues. Again, I have not run into any issues - just test. Also, unlike powershell - it will run under winpe