Virtual Machine

[mpiaser]

I am having a problem with Winbatch running in a Virtual Machine.  It doesn't type in keystrokes when it should.

When I am connected to the virtual machine (via RDP for example), everything works fine.  When I run the script (with a timer) and I'm not connected to the machine, the script runs but does not enter the keystrokes.

[Deana]

I am having a problem with Winbatch running in a Virtual Machine.  It doesn't type in keystrokes when it should.

When I am connected to the virtual machine (via RDP for example), everything works fine.  When I run the script (with a timer) and I'm not connected to the machine, the script runs but does not enter the keystrokes.

Can you provide details about the VM software you are using?

Keep in mind WinBatch SendKey and Mouse commands are not going to work on a 'locked' workstation. Is it possible the keyboard and mouse input is locked when you are not logged in? You may need to check the VM software documentation.

You mention that it doesn't send the keystrokes when it should. Does that mean that you are able to successfully send some keystrokes, however the timing is off? Please clarify.

[ChuckC]

Based on the original post description of the problem, this has nothing to do with running in a VM.

The problem is simply that the SendKey*() and mouse related functions do not work on a locked console or in a disconnected RDP session, regardless of whether Windows is running on bare metal or in a VM.

The script will need to be rewritten to work in a different manner, possibly using the Control Manager extender or COM/OLE to get around this limitation.

[mpiaser]

Virtual Machine software is VMWare ESXi 5.0.1

I have another client where we are running Winbatch similarly disconnected and Winbatch does respond to SendKey().  The obvious question is what is different between the two clients.  I don't know that answer but I am trying to find out.

[Deana]

Its seems one workstation is possibly 'locked' for keyboard and mouse input.

[td]

Virtual Machine software is VMWare ESXi 5.0.1

I have another client where we are running Winbatch similarly disconnected and Winbatch does respond to SendKey().  The obvious question is what is different between the two clients.  I don't know that answer but I am trying to find out.

If I recall correctly and as Chuck mentioned, if a session it truly disconnected, it will not be able to receive user input.  However, you can shadow (remote attach) to an existing console session and then detach from it.  When you do this, the console session's Default desktop processes will still receive user input after the detach until the session switches to a different desktop like the  screen saver/Winlogon desktop or is shutdown by logging off.

[ChuckC]

That is correct.  The physical system console session can remain in an unlocked state, and while unlocked, the SendKey*() and Mouse*() functions will work properly.

There is absolutely no ambiguity involved with how these functions behave w/respect to unlocked sessions and locked/disconnected sessions.  The only variable involved is what state the session is actually in at any given time, which may not be obvious and is implied by how these functions are behaving at any given time.

If the script will be running in a session that has any possibility of going into a locked or disconnected state, then the script needs to be rewritten to not use the SendKey*(), Mouse*() or any other functions that do not function in a locked/disconnected session.