Scheduling User Interface (UI) automation macros to occur when Windows is logged off or locked is problematic. A full user session needs to be active for a UI macro to work. Why is this? Windows consists of “Window Stations” and “Desktops”. A window station is a secure object that contains a clipboard, a set of global atoms and a group of Desktops. The interactive window station assigned to the logon session of the interactive user also contains the keyboard, mouse, and display device. The interactive window station is visible to, and can receive input from, the user. All other window stations are non-interactive, which means that they cannot be made visible to the user, and cannot receive input. So only one Window Station, and one Desktop at a time can receive keyboard and mouse input, while all others are invisible. While logged out the only thing you can do is log in. Services can run while Windows is logged out but they run in their own session and there is no desktop to interact with. So any macros scheduled from a service will run invisibly and cannot mimic user input.
Usually, if you have a UI macro which must run regularly, the simplest and most reliable approach is to schedule it on a machine which is left logged in and never logged out. Many of our clients even dedicate an old machine to Macro Scheduler. Where security is an issue they leave it locked in an office or secure computer room. This is fine where you have control of the machine, but what if you need to schedule a UI automation routine on a client’s computer and they, understandably, insist that this machine should not be left logged in?
Well, with Macro Scheduler version 8.0 we introduced the Scheduler Service and AutoLogon which allows macros to be scheduled when Macro Scheduler is not running and to automate a Windows Logon so that the full session is available. However, there are still some problems with this approach. One is that interactive services are being phased out with Vista and even in XP sometimes have problems – the concept of interactive services has always been a bit of a workaround and Microsoft are finally removing them altogether to guard against OS shatter attacks and other issues that allowing interactive services can cause. Another problem is that AutoLogon cannot work with fast user switching. Of course, the other obvious issue with AutoLogon is that although the machine doesn’t have to be left logged in, AutoLogon does mean that for the duration of the macro Windows is unlocked. For some, even this temporary log in might be unacceptable – and what if the macro fails half way through, leaving the session open?
With Vista dropping interactive services and changing the entire logon mechanism we are currently investigating whether or not there is any way we can implement an alternative AutoLogon solution. Vista is still in beta and with the Vista SDK and documentation being incomplete and sketchy it’s still too early to tell whether or not we can implement a Vista compatible version of AutoLogon. But there is already an approach, using existing Windows functionality, which works well with XP and Vista.
This approach involves two PCs and Remote Desktop Connection. The machine on which the routine must run needs to allow Remote Desktop Connections. A good guide on enabling Remote Desktop Connections can be found here. Macro Scheduler and the UI macro must be installed on this machine.
On the other machine create a Remote Desktop Profile (RDP) file. To do this click Start/Run and type mstsc.exe. On the Remote Desktop Connection dialog that appears click “Options”. You’ll get this screen:
Select the name of the computer you will connect to and enter the username and password. Check “Save my password”.
Click the “Programs” tab. Here you tell Remote Desktop Connection to run the Macro Scheduler macro:
Enter the path to Macro Scheduler’s executable followed by the macro name:
“c:\program files\mjt net ltd\macro scheduler\msched.exe” myMacro
Under “Display” you can set whether the desktop session should run full screen, or whatever resolution you like. It doesn’t really matter.
Back under the “General” tab hit “Save As” and save the rdp file.
Now, when you want to run the routine you just issue:
mstsc.exe rdpfile.rdp
E.g. if you saved the file to c:\my documents\serverauto.rdp you would run:
mstsc.exe “c:\my documents\serverauto.rdp”
When this runs, a desktop session is created and the UI macro is executed – it works because the only interactive Window Station is the one created by Remote Desktop Connection. When the macro finishes, the session is logged out again. The desktop session appears on your screen. Nothing appears on the remote machine – it remains logged out. But Remote Desktop Session creates a window session and the Macro Scheduler UI routine runs within it. You can now schedule this command to run at the required time, either in Macro Scheduler or in Windows Task Scheduler.
The beauty of this approach is that it works even when both machines are locked or logged out. The only time it won’t work is if you minimize the Remote Desktop Connection. When you do that the session stops responding to keystrokes and mouse events. So if you are logged in, leave it open.
This method is ideal for scheduling processes to run on remote machines or on customer machines, where you can control the schedule from your end. But it is equally useful for scheduling processes internally where you don’t want the machine physically logged in. Until we find a replacement for AutoLogon in Vista, it is also a nice workaround if you need to schedule macros in Vista and do not want to leave the server unlocked.
Instead of setting the macro to run in the Remote Desktop Connection dialog, you could set the macro to run on startup and have the script check to see whether the current user is logged in via the console or via RDP (to avoid it running when a regular log in takes place). An example of how to determine whether the user is logged in locally or via Remote Desktop can be found here.
With Macro Scheduler scheduling the script on the client, other ways to start the script once the desktop connection is open could include assigning the remote script to a hotkey and having the client script send the key sequence; installing msNet on the server and issuing a HTTPRequest to run the script once the desktop connection is up; or if the two computers clocks are well synchronised just schedule the script on the server to happen shortly after the desktop connection is scheduled, allowing enough time for the log in to take place. Instead of installing Macro Scheduler on the remote machine you could also compile the macro to an executable and install just the executable macro on the server, and set it to run when Remote Desktop connects.
