March 20, 2006

Running UI macros when logged out with Remote Desktop

Filed under: Automation,Scripting,Vista — Marcus Tettmar @ 9:35 am

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.

March 17, 2006

Vista Recording

Filed under: Vista — Marcus Tettmar @ 4:20 pm

Good news – we now have macro recording working nicely under Windows Vista. Macro Scheduler is able to run at the “asInvoker” level, marked as a “uiAccess” application, meaning it does not need to “elevate” and can interact with other processes – so any level of user can run it and record macros successfully.

The next challenge is to consider the scheduler service under Vista. At present admin privileges are required to start the scheduler service. Only administrators can install services anyway, so we will probably make the Macro Scheduler installer detect whether or not the user is an administrator and only install the services if the user has administrative privileges. However, Vista no longer even supports interactive services, which are needed for UI automation macros to work, so at this stage I’m not even sure if a Vista scheduler service is feasible or beneficial. In addition AutoLogon, if at all possible, will need completely re-engineering as the entire logon system changes in Vista. So we are currently looking at the feasibility of AutoLogon in Vista and how it might be achieved if it is even possible. Watch this space ….

Having used Vista for a while now, I can see the majority of users disabling User Account Control in Vista and going back to the old way of doing things – by running everything as Admin. Microsoft has done a lot of work to make Vista more secure, but the downside is the extra loops a user has to go through. For example – with a new Vista install (latest release) and no system changes – so an out-of-the-box install – I wanted to make a new directory in Windows Explorer. On doing so a box pops up saying “You aren’t allowed to do that, but do you want to do it anyway” (or something to that effect). So I click “yes”. Then another box pops up saying “Allow file control to run?”. So I click “yes”, again. So now I have a new folder called “New Folder”. Now, of course, as usual I want to rename it – I don’t want it called “New Folder”. So I hit F2. A box pops up saying “You’re not allowed to rename the folder, but do you want to do it anyway?”. So I click “yes”. Then another box says something like “Allow file control to run?”. So I click “Yes” again. Finally I can rename the folder. Phew! All that to create a new folder!? Four extra clicks! By disabling UAC and running as Admin I’d have none of that. Progress? I’m not so sure. What made Windows successful was it’s ease of use. But it is not known for being the most secure operating system. Perhaps you can have one but not the other. It seems that the more secure something is the less friendly it becomes to use, because by definition you need more controls and warnings. So it remains to be seen what happens when Vista rolls out. Perhaps by then they’d have made things simpler. If not I can see people switching off all that new technology that Microsoft have worked so hard on …

March 15, 2006

Vista Update

Filed under: Vista — Marcus Tettmar @ 12:30 pm

Some good news. I have had confirmation that Macro Scheduler will not have to run elevated at admin levels in order to set a journal hook and record macros. It will only have to be flagged as a “uiAccess” app which will allow it to record across other processes of the same security level. So a standard user will be allow to record standard processes, and an admin user will be able to record against standard and admin level processes.

That’s the theory. Unfortunately with the current Vista beta version it doesn’t actually work as described. But, hey, it’s still beta after all.

March 8, 2006

Macro Scheduler and Vista

Filed under: General,Macro Recorder,Vista — Marcus Tettmar @ 10:01 am

One of Microsoft’s main focuses with Vista is to improve security. A major problem with current versions of Windows is that to be productive you pretty much always need to be logged in as an Administrator. There are lots of day to day tasks that a regular user can’t do, but should be able to.

Because of this the vast majority of Windows users currently log in as administrators. This means they can do what they want, but since they are running everything with admin privs the system is effectively wide open. When you’re logged in as an administrator software can do pretty much anything, without your knowledge. Software that requires admin privileges will just run and perform admin tasks without warning you first. This leaves the system wide open to malware and we all know how easy it is for viruses and trojans to install themselves, and then run stealthily, leaving you with no idea of what they are doing. Problems with browser toolbars and plugins are rife. This is because with admin privileges they can install and do what they want.

To address this, Vista, by default, runs all applications with restricted standard user privileges, even if you are logged on as an administrator. By default if an application needs (or wants) administrator access it will attempt to “elevate” itself to admin level and Windows will ask you for confirmation before allowing it to run. So now whenever an admin task occurs, you get to know about it and decide whether to allow it or not. This in itself should pretty much wipe out problems with viruses, malware, spyware and adware etc. If a standard user tries to run something that requires admin privs the prompt will ask for an admin username and password. The benefit here is that an administrator doesn’t have to log off and back on again just to perform some admin task for a regular user.

What does this all mean for Macro Scheduler? Macro Scheduler’s macro recorder works by implementing what is known as a journal record hook. This hook monitors system wide events in order to record mouse and keyboard events and watch for windows to appear and disappear. I have been told by the User Account Control team at Microsoft, who are implementing the new security features, that applications that implement journal hooks may need to run at admin levels and manifest themselves as uiAccess apps. It hasn’t been confirmed yet exactly what the requirements are, but right now, in the current beta version of Vista, the only way to get Macro Scheduler to record a macro is to disable “run all apps as standard user” in UAC, so that all applications run with admin level rights. Clearly this is not an acceptable solution as it negates the whole purpose of Vista’s new security concept. The hope is that a uiAccess app will be allowed to implement a journal record hook and be able to record against apps with the same security rights. E.g. a standard user should be able to record against other standard level applications. Obviously only an admin user should be able to record against processes running with admin rights. However, there has been a suggestion that Macro Scheduler will have to run at admin levels in order to record at all. I am hoping this won’t be the case as it means only admin users would be able to record macros, where at present, anyone can. Clearly the UAC team still have some things to sort out as I am still waiting on concrete advice as to the correct solution.

Why has Microsoft changed the rules regarding journal record hooks? Well, unfortunately, these system wide hooks which monitor keyboard and mouse events, can be, and have been, used by malware to log passwords and generally implement keyloggers. And as I said earlier, because the majority of Windows users log in with administrative rights, and because up until now all applications would therefore run at admin levels, such malware could log keyboard entry without you even knowing about it. So the new UAC rules mean this can’t happen in Vista. But while I applaud Microsoft’s new rules to combat such malware, I feel it is important that they find a way to ensure legitimate implementers of these functions are not tarred with the same brush. Software like Macro Scheduler, which depend on these functions for valid uses, should not be made awkward to use by those that need to use it. So we’ll have to wait and see what the UAC guys figure out.

So stay tuned while we work with Microsoft on this. One thing is for sure though – by the time Vista ships at the end of the year we will have a fully Vista-ready version of Macro Scheduler.

« Newer Posts