12 Replies Latest reply on Apr 14, 2009 1:48 AM by phoffmann

    AutoIT issue




      i encounter this issue. You maybe know the wellknown free utility AutoIT for

      runas an executable with different credentials. When i'm logged into xp desktop

      with an account that has only user rights and manually launch an autoit

      executable that executes some commands using administrator credentials

      (RunAsSet) all works fine. If i launch same AutoIT executable using a landesk

      software distribution task, AutoIT returns an error: Access id denied - Unable

      to execute external program.




      Thanks to all






        • 1. Re: AutoIT issue





          What happens when you run the same package as local system?



          You can launch a command prompt as local system in a couple of ways to  test this.



          1: Click on Start | Run.  Then, type "at XX:XX /Interactive CMD" where XX:XX is a time in 24-hour format, preferrably 1 minute into the future.  Click " OK".  A CMD window will briefly appear, disappear and then reappear at the time you specified.



          2: Browse on the client to C:\Program Files\LANDesk\LDClient and run the following command: "localsch.exe /exe=cmd".  After about 30 seconds, a CMD prompt will open.



          Once you have a command prompt as local system, browse through it to your package and run your package.  What happens?









          • 2. Re: AutoIT issue
            zman Master


            Could be a couple of things:





            • Make sure you are using the latest build of autoitscript - there were issues with XPsp2 on some older builds.

            • As Jake indicated sounds like you may be trying to access a network exe. If this is the case try what Jake requested. Also make sure you reference the program you are running as a unc path and not drive letter.

            • Post the code.



            • 3. Re: AutoIT issue





              I think that AutoIT has problem when is runned as Local System: I found a post (even if a bit old) where there are problem to deploy AutoIT scripts with Microsoft SMS as well:












              • 4. Re: AutoIT issue
                phoffmann SupportEmployee

                Interesting find.


                You can verify if this is your problem by starting the AUTOIT script manually in a LOCAL SYSTEM CMD-box. How do you get one of those? Pretty easy actually :).


                here's what you need to do:



                1. Open a command prompt  > CMD

                2. Run the 'at' command with the following  syntax:   "at hh:mm /interactive cmd "




                at 15:46 /interactive cmd



                will launch a CMD-box at 15:46 local time on your PC


                3. At the time in the command a new command prompt window will open.  This window is running as local system.



                And that way, you can make sure that this is the problem you're running into. We usually use the above procedure to check NT-permissions on UNC shares, but it's useful for all sorts of other things when you need/want to test out whether an install (or whatever) works with LOCAL SYSTEM rights .

                • 5. Re: AutoIT issue


                  First of all, thanks to all for replies



                  I've tried /interactive test from cmd and actually AutoIT executable fails to run from this "Local account prompt".



                  I compiled with latest autoit version, but issue was not solved. Some workaround?



                  I've listen about a Landesk RunAs utility. Could it be my solution?









                  • 6. Re: AutoIT issue
                    phoffmann SupportEmployee

                    Well - that confirms you having a problem with LOCAL SYSTEM as StockTrader suggested it would be.


                    The "RunAs" tool you indicate, is not so much a "RunAs" as a specific "RunAsUser" (as in "the logged-on user") tool. This is called by a BATCH-file, and ensures that a program is launched NOT in the LOCAL SYSTEM context, but in the context of the user who is logged in.


                    Obviously, if no user is logged in, you will run into a problem :).


                    Paul Hoffmann

                    LANDesk EMEA Technical Lead

                    • 7. Re: AutoIT issue


                      This little startasuser utility made my dreams come true



                      Launched through it, my AutoIT executables are working with any user logged in.






                      Thank you very  much to all






                      • 8. Re: AutoIT issue
                        zman Master


                        Glad it worked. The issue appears to be whatever you are trying to run with runasset does not like being run in the context of the local system account (without the code we can only speculate):





                        • Trying to access network resources - as stated local system account does not have access to network resources. If this is the case map to this resource in autoit after runasset and you should be fine.  Use Unc paths to access the resource.

                        • Maybe trying to access specific user profile data that is not available - See options 0,1,2 - Default is to load the profile.



                        Autoit works very well with LANDesk, and we have hundreds of scripts we use with LANDesk. Also, be careful with startasuser since rights will not be elevated for the job, and if your users are not local admins or you have a locked down environment, you may have issues.

                        • 9. this bug is called design

                          Hi all,


                          just to explain the world you why this problem occours:


                          every RUNAS tool is unsing the windows API (if we don't have a look at the MWI things)

                          but make windows secure MS restrict using the function from local system account.


                          "CreateProcessWithLogonW Win32 API on a computer that is running Microsoft Windows 2000 or later. CreateProcessWithLogonW cannot be called from a process under the LocalSystem account."


                          Why is the landesk runAsUser is working?


                          The impersonate as the loggedonuser. With this security rights the AutoIT script can youse this windows API.


                          But now my first question:how do you make sure someone is logged in while you deploying software?

                          And the second one: are there som appliactions out there tha cannot install in system account?

                          Or why you want to do things within different user accounts?


                          Please let me know.

                          BR Butti


                          for the geeks - tech details of the windows API function:


                          [DllImport("advapi32.dll", SetLastError=true, CharSet=CharSet.Unicode)]
                            public static extern bool CreateProcessWithLogonW(
                               String             userName,
                               String             domain,
                               String             password,
                               LogonFlags         logonFlags,
                               String             applicationName,
                               String             commandLine,
                               CreationFlags          creationFlags,
                               UInt32             environment,
                               String             currentDirectory,
                               ref  StartupInfo       startupInfo,
                               out ProcessInformation     processInformation);



                          • 10. Re: this bug is called design
                            phoffmann SupportEmployee

                            Yes, there are applications out there that cannot be installed with Local System. I seem to recall an AutoCad-like package as my first "aha" experience in that regard. They're rare, but they do exist (and you should discover this during your package testing).


                            That's usually something that you want to address with the software vendor (i.e. "What's the way to distribute your software / automate installs"), though I've had (personally) also good experiences with things such as "runas" (or, the tool I use recently - CPAU, which is a free tool which can be had here - http://www.joeware.net/freetools/ ) for instance.


                            (NOTE - CPAU specifically DOES NOT work when launched from a Local System context, so you need to combine it with "run as user" as it were, for it to work, but - again - this has worked for me so far for the packages that proved to be troublesome so far).


                            Paul Hoffmann

                            LANDesk EMEA Technical Lead

                            • 11. Any other applications

                              which other appliactions are out there that are only installable with Pauls workarround?

                              Maybe the others gan give me a little feedback?!


                              Looking forward to here from you guys.

                              BR Butti

                              • 12. Re: Any other applications
                                phoffmann SupportEmployee

                                I don't think you'll stand much of a chance of getting a list of "apps that don't work with Local System context", regrettably, because the vendors don't tend to advertise this fact (it'd be a bit of a negative checkmark), if at all.


                                Usually it's enough to "educate and make people aware" that there is stuff out there, and what the possibilities are to work around this problem. Ideally, the "real" solution would be for all software to be done in such a way that local system can install it, but I suspect that this is just my idealism sneaking through .


                                Hope this helps a bit.


                                Paul Hoffmann

                                LANDesk EMEA Technical Lead