Batch file with Admin rights

[Flaterik]

Hi I'm working on locking down the PCes we are delivering, but I want to have a backup (freefilesync) running in the background on the restricted User.

I can't seem to get Autoit to start the batch file with admin rights.

 

I get it to work with Task Scheduler, but Instead of having that doing it ones a day, I want Aoutit to do it after 4 hours and starting the task in case it's not running.
I would like to not use Windows Task Scheduler as I have encountered some problems with that in the past on Windows 10. (currently still using Win7).

I can run it on my laptop (admin rights) and I can run it when logged in as an admin, so the batch file works. I think that there are some thing with the Admin rights that I have gotten wrong:

Local $iReturn  = RunAsWait($sUsername, @ComputerName, $sPassword, 2, '"' & $filesyncprog & '"' & " " & $filesyncbatchprog, "", @SW_HIDE)
            Select
               case $iReturn = 0
                  _FileWriteLog($LogFile,"Synchronize PSVs completed without warnings!")



$filesyncprog = "C:\FreeFileSync\" and "filesync.exe"
 $filesyncbatchprog = "C:\Backup\" and "backup_batch.ffs_batch"

 

Edited November 13, 2017 by JLogan3o13
Added code tags

[JLogan3o13]

@Flaterik welcome to the forum. First off, if you use code tags ( the <> button on your toolbar when posting) you get a nice scrolling box that is easier to read. I have done it for you this time to demonstrate. Secondly, please post full code or at least as much as you're able; half a Select statement doesn't help us help you

Regarding your question, you have the select statement looking for $iReturn to be 0, but we see nothing after that. What is $iReturn actually returning? Use ConsoleWrite or a MsgBox to ensure it is coming back as the value you would expect before we troubleshoot any further.

[Starf0x]

Hi Flaterik,

It might be a better idea to see why the program needs admin rights and open these area's for the normal user.

Regards, Starf0x

[Flaterik]

Hi,

 

I only posted the code that I believe is the problem. I have been running the same code prior to locking down the user rights (previously we only used Admin user).
The only "new" code regarding user rights are the

Local $iReturn  = RunAsWait($sUsername, @ComputerName, $sPassword, 2, '"' & $filesyncprog & '"' & " " & $filesyncbatchprog, "", @SW_HIDE)

As well as new variables for username and password.

JLogan3o13: It always return 0, but it does not start the program

Old code:

Local $iReturn  = ShellExecuteWait  ( $filesyncprog, $filesyncbatchprog )

Old code works fine, and the new code works fine on my laptop (runs as admin), but not on the computer that runs as a User.

[Flaterik]

I checked the Windows Event log as well to see if there was any info there. And I can see that there is an Log OFF 'User' and log ON 'User' event every time this code is run. I can verify this by a timer and separate log file I have in the code.

[Jos]

23 hours ago, Flaterik said:

$filesyncprog = "C:\FreeFileSync\" and "filesync.exe"  

$filesyncbatchprog = "C:\Backup\" and "backup_batch.ffs_batch"

This can't be right... just try:

$filesyncprog = "C:\FreeFileSync\" and "filesync.exe"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $filesyncprog = ' & $filesyncprog & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

Should be just:

$filesyncprog = "C:\FreeFileSync\filesync.exe"  

-or-
$filesyncprog = "C:\FreeFileSync\" & "filesync.exe"  

Jos

[Flaterik]

1 minute ago, Jos said:

This can't be right... just try:

$filesyncprog = "C:\FreeFileSync\" and "filesync.exe"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $filesyncprog = ' & $filesyncprog & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

Should be just:

$filesyncprog = "C:\FreeFileSync\filesync.exe"  

-or-
$filesyncprog = "C:\FreeFileSync\" & "filesync.exe"  

Jos

And your right, it's not even part of the code, I just wanted to explain what the Variables are in short. 
@JLogan3o13 converted a litle to much to code, and I can't edit my post yet.

  There is nothing wrong with the path or the variables. I just din't want to include them as the path is not relevant. Other than the .exe is not directly under C:\

The code for the path is checking an .ini file for the correct path or using a default path. This is however not part of the problem as I have this working fine.

 

I only have problems with the 

RunAsWait($sUsername, @ComputerName, $sPassword, 2, '"' & $filesyncprog & '"' & " " & $filesyncbatchprog, "", @SW_HIDE)

So I was hoping for some tips on what to look for try.

[Jos]

2 hours ago, Flaterik said:

And your right, it's not even part of the code, I just wanted to explain what the Variables are in short.

It really helps when some real code is shown as that will only trigger proper responses as we are sailing blind here.

Jos

[BrewManNH]

First thing I'd do is remove the @SW_HIDE to see what's happening. Second, try using $RUN_LOGON_NOPROFILE (0), or $RUN_LOGON_PROFILE (1). Using $RUN_LOGON_NETWORK (2) probably isn't going to work with a local account.
   

[xrxca]

On 11/13/2017 at 8:19 AM, Flaterik said:

I get it to work with Task Scheduler, but Instead of having that doing it ones a day, I want Aoutit to do it after 4 hours and starting the task in case it's not running.
I would like to not use Windows Task Scheduler

I really believe the best way to occasionally trigger items with admin access on locked down systems is with the Task Scheduler, otherwise your left with authentication issues.

It's fairly easy  to trigger a task (see schdtasks.exe)

local $cmdline = @SystemDir & '\schtasks.exe /run /tn "Do Sync (Task Name)"'
Run($cmdline, @SystemDir, @SW_HIDE)

RunWait is a different matter, the program run by the task would have to signal the waiting program in some way when it completed. (many possibilities, semaphores maybe, or just a registry or filesystem change)

There other more complicated ways to trigger a task (WMI/Objects) but the simple run of schtasks.exe works for us.

We have a number of tasks that do not have triggers in the task scheduler, but are triggered by autoit scripts (I'd have to revisit the scripts in question, but I seem to remember that a normal user can start a task that has admin rights, one of our scripts allowed a user to trigger a sync to a backup location, the program in the task creating a shadow volume, doing an ffsync from that. then removing the shadow, and the shadow stuff requires admin access.) (maybe the current version of ffsync has volume shadow support (not sure) but when the scripts were written it didn't)

 

Edited November 14, 2017 by xrxca