GUI automation and locked computer or remote desktop

[daluu]

Making a post to see if others have the same experiences and if there are workarounds to the issue or if the workaround requires modifying the AutoIt GUI automation script code.

I'm using AutoIt thru COM/ActiveX w/ VBScript but I'm sure the issue is the same with the native AutoIt script.

I've noticed that running AutoIt GUI automation (that usually requires an interactive session/logon, I think) has some issues if the following are involved: computer is locked, automation was run within a remote desktop session, or remote desktop was used to access the console session of computer and later disconnected, where console session was running the automation.

It seems that when computer is locked (purposely or due to remote desktop locking the console session (Windows XP and 2003), the automation does not run.

The following 2 cases occur:

• if automation was running, it will pause execution until computer is unlocked
• if automation is called remotely, via psexec, etc., after computer is locked, automation will fail. I have some scripts that return the GUI window detection function's return code. In this case, the return code indicates failure. Unlocking the computer fixes the problem.

This kind of sucks when you don't have enough hardware or workspace to have a physical KVM connected to a PC that's running AutoIt automation. Alternative is to use VNC but that's kind of slow & requires installing VNC.

Is there any other workaround besides modifying code or using VNC or not locking the computer?

For code changes, what can be done such that the GUI automation still executes when the computer is locked?

What my GUI automation does is to perform manual GUI config tasks as a "bot" and also does some window detection (do this if window exists, else do something else or fail).

[zfisherdrums]

Hmm. Interesting. Just this last week, I encountered a problem in an automation script where the script would hang on a remote desktop session. I later found out it was because of an infinite loop created by a custom wait function that keyed off the mouse cursor ( apparently a locked computer will not update the mouse cursor...who knew? ).

However, many of our scripts are running correctly via RDP. Do you have an example of a script that is failing consistently?

[daluu]

...many of our scripts are running correctly via RDP. Do you have an example of a script that is failing consistently?

Here's a simple example snippet in vb script:

Set ecombot = WScript.CreateObject("AutoItX3.Control")
'Set mouse coordinate system relative to the Ecom window
ecombot.AutoItSetOption "MouseCoordMode", 0

Dim retVal 'return code or value
'...
'click OK button from popup window of Ecom pause command or
'text message command. Ecom popup windows do not seem to allow 
'reading message text
ecombot.WinActivate "Information", ""
ecombot.Sleep(1000) 'wait 1 sec for window to focus
retVal = ecombot.WinWaitActive("Information", "", 5)
If retVal = 1 Then
    ecombot.Send "{ENTER}"
    WScript.Echo "Information popup found."
Else
    WScript.Echo "Information popup not found."
End If

And when I use AutoIt APIs to send text, mouse click, etc., they don't work as well when the PC is locked.

In the sample above, the VBScript executes (when called remotely) but AutoIt command seems to pause or not run. The timeout of 5 sec occurs and hence retVal is 0. And all this happens while the window to detect is actually there, and is the active window, just before the computer is locked.

In the other examples of where I'm running a VBScript with AutoItX locally, automation is running. I then lock computer, expecting automaion to continue to run (do it's configuration). When I unlock PC, I see that AutoIt is still left at where I last locked the computer - the additional configuration does not occur. Once unlocked, I see AutoIt resumes execution.

I've tested these against Windows 2003, but I'm guessing same thing will happen with XP.

Now as I say, there's no issue with RDP, but you need to keep the RDP session active. And in terms of the console session - it must be unlocked - if you RDP'd to console then disconnect, RDP is not active but your session is still available on the physical KVM - you must unlock from KVM or reRDP to console to keep it "unlocked" or I guess "really active". That's a pain.

I know some programs can still operate while computer is locked like file downloads, file transfers, disk defragmentation. I wish GUI automation was the same.

[zfisherdrums]

I see what you mean. A simple message box does not even respond to window activation messages even on a locked local workstation. Interesting. Perhaps its a security feature that windows maintains - if the user is logged out, they probably wouldn't want a nefarious automated agent running window operations in the background.

I was able to find a workaround, assuming you're still interested:

Set ecombot = WScript.CreateObject("AutoItX3.Control")
'Set mouse coordinate system relative to the Ecom window
ecombot.AutoItSetOption "MouseCoordMode", 0

Dim retVal 'return code or value
'...
'click OK button from popup window of Ecom pause command or
'text message command. Ecom popup windows do not seem to allow
'reading message text
ecombot.Sleep(1000) 'wait 1 sec for window to focus
If ecombot.WinExists( "Information", "" ) = 1 then
    ecombot.ControlFocus "Information", "", "OK"
    ecombot.ControlSend "Information", "", "OK", "{ENTER}"
    WScript.Echo "Information popup found."
Else
    WScript.Echo "Information popup not found."
End If

Edited September 16, 2008 by zfisherdrums

[daluu]

thanks, I'll try that out sometime. hope it works for my case.

Edited September 16, 2008 by daluu