3 Replies Latest reply on Mar 2, 2010 8:27 AM by jmac

    Trouble distributing installers from VBScript


      We've run a little snag with distributing software through LANDesk.


      We use LDMS 8.8 SP3 to distribute software packages to Windows Vista SP1 machines based on membership of an Active Directory security global group. We've created a policy delivery method, about 140 distribution packages and as much scheduled tasks. LDAP queries were made to use as targets for our scheduled tasks.


      This setup works like a charm, except for a few dozen packages. These packages consist of VBScripts which install multiple package and most of the time contain other actions pre and post setup. Due to our security baseline, UAC must be enabled on the client machines. This forms an issue when distributing VBScripts through LANDesks standard distribution packages for VBscripts. As the script is run, WScript is executed as "local system" user and UAC will kick in showing a "Show me the message" screen to the logged in user when the script gives output to the screen.


      We tried to circumvent this problem by "packaging" the scripts as an executable, so we can use the executable distribution package to run as Current User. Alas, this option only archives the script into a self extracting archive, which extracts the script locally and executes it from there. This gave us another set of problems, so we've abandonned this. We've tried a nes method by using LANDesks startasuser.exe to run WScript.exe on current user credentials. The script now runs as the currently logged in user. Problem solved you should think, but no.


      We use a policy delivery method to distribute all software. The scheduled tasks are run every hour. This is to support demands for easy and fast automatic software distribution. We add an user to a security global group, the scheduled task is executed every hour to distribute the software and the LANDesk LDAP query resolves the members to target.


      Now, for every distribution package, whether it's an executable setup (setup.exe) or a MSI, the installation on the client is run once, only the first time when the software isn't distributed before. The next time the scheduled task is started, only new targets or failed attempts to distribute the package are targeted. With the above mentioned way using VBScripts to install the software, users complain that the software is distributed every day, multiple times a day, even if the package is distributed correctly (result: succes).


      This is a problem we haven't solved yet.


      All these distribution packages are executable distribution packages which start startasuser.exe from a network location (permissions are checked and correct) with wscript.exe and the VBScript as an parameter in Install/Uninstall options. The distribution package is run as Current User.


      We like to know why this is happening and how we can succesfully deploy these scripts without disabling UAC (no option) and without the packages deploying over and over.


      Thanks in advance.



        • 1. Re: Trouble distributing installers from VBScript

          As I was typing the above, I realised using startasuser.exe distributed through an executable distribution package isn't the answer either.


          Even if the package is distributed succesfully, it's always based on the correct execution of startasuser.exe, which is run for all scripts. So, in theory, if one script is succesfully executed, all are, right?

          • 2. Re: Trouble distributing installers from VBScript

            Talked to support and an engineer a few days ago.


            To put it simple: not gonna work as we want it to.


            Guess it's back to the drawing board for us.

            • 3. Re: Trouble distributing installers from VBScript

              Mom always told me to say nothing if you have nothing nice to say, so I won't comment on UAC and how much of a bad idea it is in a Domain environment.


              Without knowing much about the apps you are deploying, have you tried using Dependant Packages in your Distribution Packages? It works well with MSI based apps and might help you get past the problems you are having. You could also try a provisioning script which I have a good luck with, but again mostly with MSI's.