AutoIT exes as Configuration Manager programs

[cliftyman]

We push a lot of msi's using System Center to our machines but we also like to wrap our processes in AutoIT compile executables.  We usually use ShellExecuteWait and windows commands to acheive what we need to do.  We've found however that this causes a lot of problems as far as path declaration is concerned.

I've been playing around with running AutoIT native functions instead.  When we compile AutoIT functions such as DirRemove into an executable and push them to our workstations they run as a child process of CCMexec in the Local System Administrator accounts context.

We've noticed that these exes just hang and never seem to do anything, but if we run them on our own machine as a local administrator account they work perfectly.  Can anyone tell us why this is?  Thanks!

[JLogan3o13]

What credentials are you setting the install to run under, when you configure it in SCCM?

[cliftyman]

We have a very detailed security policy and all our machines have UAC enabled.  I specify all of our programs to run as administrator so in CCMexec that means the program runs as the LSA and when the program is delivered by CCMexec.exe I see the child process (my program) running under the local system account.

When I run my script on my machine as my local administrator account it runs fine but when it runs on our test machine under the LSA it doesn't run.  I personally think this has something to do with it... will DirRemove not run under the LSA?

[JLogan3o13]

What permissions have you given the service account on the local boxes?

[cliftyman]

If you mark a program to "run as an administrator" which we have it runs your script under the LSA (Local System Account) in Windows.

[JLogan3o13]

Sorry, I wasn't being clear. What I was getting at was, when you implemented SCCM, did you implement a service account that you could try it under. I would be curious if you see differences between running as System vs an SCCM admin account. I had a client that encountered such issues (admittedly, under SCCM 2007) that we had to work through.

Edited August 22, 2014 by JLogan3o13

[cliftyman]

I didn't realize I could implement a service account to run programs as administrator under.  I thought it was LSA only when you checkmarked that option.

I will look into that.  I'd be willing to bet that running it as a local admin on the remote machine through CCMexec.exe will make it work.  I'm still curious why the script won't run as the LSA.  I know the LSA is not a standard account and doesn't have some portions of the registry hive associated with it.  I wish I understand the difference between the LSA and local admins better. (detailed in plain english and not from a technet article!)

[Gav]

Sorry to drag up an old thread but this noob is having a similar problem.

Background:

I want to push out a usb driver to a lab full of (Windows 7x64) machines.

Have used psexec before and worked well, imported the security certificates onto the PC first by GP, then ran dpinst-amd64.exe.

This particular driver is causing me problems however. I import the security certificates into trusted publishers as before BUT the driver still pops up the window Would you like to install this device software?

Manually I've ticked the box Always trust software from "manufac..." and clicked the install box and the install continues successfully. If I then run dpinst-amd64.exe again (even though it's just installed them) it STILL pops up the box Would you like to install device software? and the box Always trust this software from "...." is displayed. Bug I guess.

So I've turned to AutoIT for the first time.

I've managed to record either my keypresses or mouse clicks and it works well when I click on the compiled exe as an admin user of the pc.

However, we use Microsoft SCCM 2012 to push out applications and when the program gets cached to the lab pc it ONLY runs as SYSTEM and this is my problem.

I think because it's run as SYSTEM, it does/cannot display the GUI?

Is there a way of running my exe as SYSTEM and display the GUI?

As as side note, there is an option for running the program as SYSTEM interactively but only when a user is logged in. I'd rather not use this option and have the driver pre-installed when a student wants to use the PC the driver would be ready and waiting....

 

Sorry if this is a lame question but I did search and this was the closest question to mine but not resolved :-(

 

[JLogan3o13]

@Gav why are you not using the silent switches that come with that install package? Create a package in SCCM, install as SYSTEM with a Silent, Forced, Accept EULA switch, and done.

Edited December 3, 2015 by JLogan3o13

[Gav]

Hi jLogan3o13, thanks for your reply. I'm pretty sure I tried that and it failed silently. But I'll give it another go as I can exactly remember.....

 

 

EDIT when I run psexec -s dpinst-amd64.exe /S /F /SA /SE /SW it gives the error -2147417344 which I think is 0x80240020

I googled for 0x80240020 and got "This is an expected message indicating that when installation begins it may require user interaction."

Which sort of makes sense, but means it's not running silently....

running it as an admin gives nothing, I can see for taskmgr that dpinst-amd64 starts briefly then stops. Running dpinst-amd64 interactively gives the results as if I've never run it before :-( so that means it's not completing...

Edited December 10, 2015 by Gav

[JLogan3o13]

Maybe I am misunderstanding you. You are deploying this through SCCM as a package, correct? If so, why are you then using PSExec? SCCM will run the package as System for you, which is all psexec -s is doing. Can you explain why you need to run it through PSExec on each machine?

[Gav]

sorry my fault -didn't want to make the post too long.

Yes SCCM only runs the package as SYSTEM. To test my compiled exe I'm using psexec -s to simulate SCCM.

This way I can see what would happen overnight when no user is logged in.

Hope this makes sense!