2 Replies Latest reply on Sep 5, 2009 12:16 AM by ecoidan

    Windows Script Not Executing At Client


      I am executing a script which automates the 'runas' command by taking credentials as command line options along with a command to an executable. From a local machine this would be run as:


      wscript vbrunas.vbs domain\admin password command.exe



      This works locally, however when deployed as a Windows Script Host distribution package with the appropriate command line options, it fails after authenticating the runas command. This was verified by removing the automated password entry in the script, so that at deployment time, the package prompts the client for the password, which is entered but the actual executable fails to run. Numerous executables were scripted (trivial applications such as notepad, calc, etc) but none of them ran at deployment time.


      Does this have to do with the script being run from the LocalSystem account?

        • 1. Re: Windows Script Not Executing At Client

          for clarification purposes, the vbrunas script, in short, executes this:


          /runas domain\admin command.exe


          when the shell prompts for the admin password, the script enters the password string and executes the command



          the script was deployed successfully using a batch file installation under the current user account (as opposed to the Local System account), but this method is unfavorable as the batch file containing administrative credentials would be downloaded to the client machine. However, can someone explain why the script successfully runs commands from the current user account and not the local system account?

          • 2. Re: Windows Script Not Executing At Client
            ecoidan Specialist

            Edit or ReWrite your VB to run STARTASUSER before the RUNAS functions




            Package your vbscript in a SWD, have it dropped your VBScript on the system and have the SWD run a STARTASUSER with your VBScript Name and parameters.



            Either way you'll need to have it run at Next Login with a STARTASUSER.  Why at Next Login? Because STARTASUSER does you no good if no one is logged in. My 2 cents worth...