Tim H.

Jos: I was running the script by double-clicking it on my desktop. While I was playing, I got the command to work by using a target path that contained no spaces and, consequently, fewer quotes. That had me scratching my head since the syntax with the longer target path looked right. Then I saw your reply. Given your question, I put the script and a copy of psexec.exe in c:temp, opened a command session there, typed in the script's name, hit enter and "presto chango" it worked! Next, I figured either psexec had to be in the same directory as the script or running the script from a path with spaces in it was causing the problem. So, I deleted the psexec executable from the c:temp directory and tried it again thinking the long target path with spaces might be the problem. But no, It failed again. Lastly I changed the non-test command string in my script to include the full path to the psexec executable like this: $cmd = 'C:SysinternalsPsExec ' & $ComputerName & ' -s XCOPY ' & '"' & $LocalSource & $aFile[$n] & '" "' & $LocalPath & '" /Y' (hard to read with the mixed quotes and apostrophes) and double-clicked it on my desktop. That worked too. So, something about relying on psexec being in my path environment was causing the problem. I went and looked at my path environment to find that psexec's directory was not in the path. So, I double-checked to see if there was a copy in either C:Windows or C:WindowsSystem32. There wasn’t. Installing PSTools must put an entry into the Windows registry so the executables are available from anywhere. Apparently though, that's not good enough. Any idea why that would be? Anyway, problem solved for now. I appreciate your help!

Jos: I tried both Shellexec() and "@comspec /c " Shellexec tells me there's no file type associatied in the registry (there isn't for psexec) and adding "@comspec /c " in front results in the same: Parsing error code 4 Tripredacus: I'm not sure what adding the extra quotes (Chr(34)) is meant to do, but I tried it anyway with the same result. I expected to see the extra quotes in the message box, but didn't. Any other thoughts?

By the way, 7zip has free-standing command-line tools that will let you automate encryption of files (AES256). Then you can just use regular FTP commands to transfer them, as long as your destination host accepts regular FTP connections on port 21. This could be another way to go without having to write an AutoIt script.

The command-line PuTTY tools don't need to be "installed" per se. Its files need only be available. psftp.exe is probably the only executable you need. You can extract the files on one machine and then just copy them to another. The chm help file is useful for understanding the syntax. The command line might look something like this: C:Puttypsftp HostAddress -b ftpbatchout.psftp -bc -be -batch -l AcctID -pw SFTPPW The ftpbatchout.psftp reference is to a text file that contains your sftp commands, something like this: # PuTTY script file lcd D:Putty***FTPFilesOut cd "/RemoteDirectory/" put MyFileName quit

In task scheduler, on the "General" tab, do you not have the "Run whether user is logged on or not" radio buttion option?

The PuTTY tools are comprehensive enough that AutoIt may not be needed. That was the other cat-skinning option I was suggesting. Of course, depending on what icu means by "data from an AutoIt program" my suggestion could be completely invalid.

I use PuTTY command-line tools (opensource freeware) on a daily basis to tranfer files securely with SSH2. I haven't tried running them from within an AutoIt script, but I see no reason why they wouldn't function properly. Depending on the complexity of what you're trying to do, you may be able to get by with simple batch files and SFTP scripts.

From within an AutoIt Script, I'm trying to use psexec with system authority to copy files from one place on a remote machine to another. When I issue the necessary command outside of the script (at a command prompt), the command executes properly. Here's the exact one-line command: psexec \\vmhartlti01 -s XCOPY "C:\temp\hs\Hyperspace POC.lnk" "C:\Documents and Settings\All Users\Application Data\Landesk\ManagementSuite\Launchpad\Dept Apps\" /Y When I try to run the exact same command from within an AutoIt Script, an XCOPY parse error 4 flashes up for a millisecond in the console and the command fails. The command appears to be formed properly in the message box popup. $cmd = 'psexec \\vmhartlti01 -s XCOPY "C:\temp\hs\Hyperspace POC.lnk" "C:\Documents and Settings\All Users\Application Data\Landesk\ManagementSuite\Launchpad\Dept Apps\" /Y' MsgBox(4096, "test", $cmd) $XCopyStatus = Run($cmd, "c:\temp") The Run command returns the XCOPY PID rather than zero, further obfuscating the problem. I've been working on this for a while now and I think I must be missing something. Does anyone see the problem? Thanks for your help.

Glad I could help.

There is no way to record a pause that I'm aware of. You can use the sleep() function if pause time is predictable. But, I think it's better to capture what's going on with the screen in a loop and watch for an indicator heralding the next step.

Another thing to try is using key sequences rather than mouse clicks, if your app will let you do so. Alt and the first letter of the menu item will sometimes work even if letters in the menu name aren't underlined. I almost always use key strokes rather than mouse clicks for navigating from within a script.

Does the ScriptWriter generated code behave the same way?

If you didn't capture the click sequence and coordinates with ScriptWriter, you might want to do so and compare its output with what's in your script. Also, try increasing the time between clicks. I've had lots of issues where click timing was the problem.

It's probably simpler and makes more sense to just use psexec. I was hoping for a set option like: AutoItSetOption("SystemGUIInteract", 1) Thanks for trying. I appreciate your time.

Make sure the screen resolution is the same on both machines. Screen coordinates on one resolution are different on another.

"System" can indeed display message boxes. If I open a command session with psexec and the -i parameter: psexec.exe -i -s %SystemRoot%\system32\cmd.exe Launching the script from the command prompt, results in display of the message box. I can run the installation I'm trying to run using my distribution application's "current user" mode instead of "system" and then use RunAs referencing an account that's a member of the local administrators group; but, doing so increases complexity and generates other issues. Oddly, using RunAs() under the "System" account doesn't seem to work. Any other thoughts?

My exact syntax is: $RebootStatus = MsgBox( 262144+4+4096, $CMDline[1] & " has been installed.", _ "You must reboot for " & $CMDline[1] & " to function properly." _ & @CRLF & @CRLF _ & "Do you want to reboot your computer now?", $MsgTimeOut ) I'm thinking I may have to use SysInternals' PSExec

I had already tried adding 4096. No joy.

I'm using a software distribution system that allows me to run installation executables, MSIs, etc. with System Authority. When I attempt to display a message box running an AutoIt script under System Authority, the current user can't see the message box. Is there an AutoIt setting that enables the System account GUI and current user account GUI to interact with each other? Or, am I thinking about this all wrong? Any help would be appreciated.

Resurrecting this thread two years later: I have the same issue. System authority doesn't do it. The ugly application I'm trying to install requires that the user be an actual member of the Local Administrator group. The user's profile is updated during the installation process so I can't use an alternate account to perform the installation. I can add the user to the local administrators group easily enough, but unless the user logs out and in again, administrator rights are not realized. Has anyone found a way around this?

Turns out the person that was able to mouse and type during the BlockInput() was remoted into the machine that was running the script. As far as I'm concerned, in that scenario, all bets are off. BlockInput() was working fine from the local user's perspective. Thanks again.

I just realized there was no sleep in the example. When I put one in, the example worked fine. Now I have to figure out why the real script isn't functioning properly. I took someone elses word for it and thought I reproduced the problem with the example script. (duh). Thanks and sorry for the oversight.

Running 3.3.0.0, even the canned BlockInput help example doesn't function correctly. BlockInput(1) Run("notepad") WinWaitActive("[CLASS:Notepad]") Send("{F5}") ;pastes time and date BlockInput(0) Running the example, compiled or not, I'm able to mouse around and type in the notepad session that opens. Has anyone else seen this? (USB keyboard & XP SP3) Thanks

Something else is going on in my environment. When I run the script locally with the local administrator account's credentials, it runs perfectly. When I run it locally with the domain credentials of an account in my local administrator's group, it runs perfectly again. When I try to run it from my network using UNCs (ignoring any drive mapping issues) , it fails. Perhaps I have a latency issue or a NAS attribute problem that's precluding the second instance from launching. At least I have a working scenario. Thanks again for your help.

Thanks for the quick response. "Bad Credentials" were my first thought too. I tried three different sets, all of which I verified were correct and operational. I'll keep playing with it.