Running compiled scripts over the WAN

[DeFuser]

Hello all,

I am new to this AutoIT thing and am still working on basic "install software" or "tweak the registry" stuff, but I already find myself thinking "you know, I could automate that." Although I am just beginning to scratch the surface I can tell that this is going to be a great ride.

My question today concerns running compiled scripts over the WAN. All of my nifty code morsels are on the server in our main office, and sometimes when installing software on a PC in a remote location (via Remote Desktop or Dameware) the script stops. I am thinking that the subsequent window is popping up before AutoIT is ready for it (although the scripts are at this location, each site has a copy of the application installation files on their local server).

What do you think is the best way to approach the problem? The three solutions I have come up with are as follows, but feel free to tell me if there is a better way.

1) Increase the WinWaitDelay time

2) Use WinWait in lieu of WinWaitActive

3) Copy the AutoIT file locally

All ears,

Def

[Oxin8]

I sometimes find myself doing a combo of WinWait, WinActivate, and WinWaitActive. Something like this maybe...

Func MyWinFunc($mywin)
WinWait($mywin)
WinActivate($mywin)
WinWaitActive($mywin)
EndFunc

hope that helps.

[DeFuser]

I sometimes find myself doing a combo of WinWait, WinActivate, and WinWaitActive. Something like this maybe...

Func MyWinFunc($mywin)
WinWait($mywin)
WinActivate($mywin)
WinWaitActive($mywin)
EndFunc

hope that helps.

Hehehe, well that certainly doesn't fall into the "eloquent" category, but I'm not opposed to going the duct tape and bailing wire route if need be ... On second thought, I just may be inclined to copy the rascal to the local drive first

[billmez]

Hello all,

I am new to this AutoIT thing and am still working on basic "install software" or "tweak the registry" stuff, but I already find myself thinking "you know, I could automate that." Although I am just beginning to scratch the surface I can tell that this is going to be a great ride.

My question today concerns running compiled scripts over the WAN. All of my nifty code morsels are on the server in our main office, and sometimes when installing software on a PC in a remote location (via Remote Desktop or Dameware) the script stops. I am thinking that the subsequent window is popping up before AutoIT is ready for it (although the scripts are at this location, each site has a copy of the application installation files on their local server).

What do you think is the best way to approach the problem? The three solutions I have come up with are as follows, but feel free to tell me if there is a better way.

1) Increase the WinWaitDelay time

2) Use WinWait in lieu of WinWaitActive

3) Copy the AutoIT file locally

All ears,

Def

Something else to consider...

If the AutoIT scripts run on a local system without a problem, I don't see how it can be a timing issue since it is still running on a local system (remotely), unless the software you are installing is also coming from a remote server and not local to the system you are installing it on.

Maybe AutoIt is just not picking up the window you intend it to for some reason. If you are in a remote desktop session it is possible for a window to be opened in the console that you will not see or may not even have access to see in task manager.

Just a thought.

[DeFuser]

... unless the software you are installing is also coming from a remote server ...

I think that is the case. The scenario is like this - I am in Houston, along with our local server where both the AutoIT .exe files and the application files reside. I can run installations all day long without a hitch (so far)

When I remotely log into another machine (say in Dallas) I'll install the application from the Dallas server, but I'm still kicking-off the process from the AutoIT .exe in Houston.

I do find it odd that latency would factor in with such a small .exe ... Then again, I am not too proud to admit that I may be way off-base with the timing theory. I was just wondering if others have run into similar issues.

Cheers,

Def

[billmez]

I do find it odd that latency would factor in with such a small .exe

While incresing the delay or even using controled looping might work, it would seem to me that if the software is already on the local server, the most dependable answer would be to copy the scripts to each local server and run them there.

Have you considered an AutoIt script to automate deploying the scripts to the remote servers too?

[DeFuser]

Have you considered an AutoIt script to automate deploying the scripts to the remote servers too?

First off, let me say thanks for your input on this.

Are you suggesting replication of the script folder to each of the remote offices, or copying the required script to the local server on an as-needed basis and then deleting it? In regards to the former, we have 9 offices and I'm not too keen (from a purely administrative point) of having to maintain up-to-date copies at every location. If you're suggesting copying the script to the local server on an as-needed basis, I may as well set it up to run from the hard drive of the system getting the install (vile latency, take that ).

I really thought that this would be a common scenario with a "try this command instead" or "adjust this parameter" type of fix, but it looks as though I'll be going with the billmez "script to automate deploying the scripts" idea ... I'll just be deploying to the local hard drive.

Enjoy your weekend,

Def

[Jos]

I don't really see the difference running it locally or remotely other than the time it might take to load the script, but after it is loaded it is in memory and only then starts executing, so that shouldn't be causing issues.

You then kick off an installer from a "local" fileserver so that should be the same for each scenario as well.

Only difference i see is the way the "session" runs on the PC (RDP/Dameware)

You have to show some of the script code that is failing for us to be able to see if you have things in there that might cause these issues and explain exactly what your script is failing on when running remotely.

[DeFuser]

You have to show some of the script code that is failing for us to be able to see if you have things in there that might cause these issues and explain exactly what your script is failing ...

WinWaitActive("MicroStation Setup", "Setup has finished")
    Send("{ENTER}")

    WinWaitActive("MicroStation V8 2004 Edition ReadMe")
    Sleep(1000)
    WinClose("MicroStation V8 2004 Edition ReadMe")

    WinWaitActive("C:\Documents and Settings\All Users\Start Menu\Programs\MicroStation")
    Sleep(1000)
    WinClose("C:\Documents and Settings\All Users\Start Menu\Programs\MicroStation")

Else
    MsgBox(48, "Microstation V8 is already installed. Moving on to PDF Composer installation.", 3)
EndIf

; ===== End Microstationv8 installation ===== 
; ===== Start Microstation PDF Composer installation ===== 

If FileExists("C:\Program Files\MicroStation PDF Composer\")=0 Then 
    MsgBox(64, "Status", "Beginning PDF Composer installation.", 3)
    Select
        Case $location = "Houston"

After examining the code as you suggested the two "Sleep(1000)" comments stood out like a sore thumb. I remember having to throw those into the mix in order to get the final nag windows to close properly. Strangely enough, this is where the script stalls during remote installs.

Come to think of it, the remote offices generally have older (slower) machines and run Win2K as opposed to XP ... I'll try bumping that value see what happens. Can you suggest a better method to kill those last two windows?

Thanks for pointing me in the right direction!

Def

[Jos]

WinWaitActive("MicroStation Setup", "Setup has finished")
    Send("{ENTER}")

    WinWaitActive("MicroStation V8 2004 Edition ReadMe")
    Sleep(1000)
    WinClose("MicroStation V8 2004 Edition ReadMe")

    WinWaitActive("C:\Documents and Settings\All Users\Start Menu\Programs\MicroStation")
    Sleep(1000)
    WinClose("C:\Documents and Settings\All Users\Start Menu\Programs\MicroStation")

Else
    MsgBox(48, "Microstation V8 is already installed. Moving on to PDF Composer installation.", 3)
EndIf

; ===== End Microstationv8 installation ===== 
; ===== Start Microstation PDF Composer installation ===== 

If FileExists("C:\Program Files\MicroStation PDF Composer\")=0 Then 
    MsgBox(64, "Status", "Beginning PDF Composer installation.", 3)
    Select
        Case $location = "Houston"

After examining the code as you suggested the two "Sleep(1000)" comments stood out like a sore thumb. I remember having to throw those into the mix in order to get the final nag windows to close properly. Strangely enough, this is where the script stalls during remote installs.

Come to think of it, the remote offices generally have older (slower) machines and run Win2K as opposed to XP ... I'll try bumping that value see what happens. Can you suggest a better method to kill those last two windows?

Thanks for pointing me in the right direction!

Def

One of the first things that comes to mind when ppl say the script stalls is that they have a WinWaitActive() in the script. WinWaitActive() means the Window exists AND has the focus.

I try to avoid WinWaitActive() and use WinWait() (and do WinActivate() is the window has to have the focus and I cannot use Controlxxx commands.