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?
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.
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:
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 .
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?
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 :).
LANDesk EMEA Technical Lead
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
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.
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.
for the geeks - tech details of the windows API function:
[DllImport("advapi32.dll", SetLastError=true, CharSet=CharSet.Unicode)]
public static extern bool CreateProcessWithLogonW(
ref StartupInfo startupInfo,
out ProcessInformation processInformation);
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).
LANDesk EMEA Technical Lead
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.
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.
LANDesk EMEA Technical Lead