March 22, 2006

WebRecorder 1.71 Update

Filed under: Announcements — Marcus Tettmar @ 12:56 pm

We’ve updated IEAuto.DLL with the ability to identify elements by their TITLE, ID and numeric INDEX in the ClickTag function. Some people have found websites where a number of ‘A’ elements (links) have identical text and no unique identifiers. WebRecorder will record these but the script may not play back – or only the first link will get clicked. The code can now be modified to identify such elements with either their title or id. Or if they have no title or id you can now resort to using the numeric index. WebRecorder Info.

Vista Delayed

Filed under: Vista — Marcus Tettmar @ 9:06 am

Microsoft have just announced that Vista will be delayed and won’t be generally available until the beginning of 2007. Read the official announcement.

This doesn’t really surprise me. Since November 2005 we have been working with the Vista beta releases to ensure Macro Scheduler will be Vista ready. Finding the information we needed to achieve this has been difficult and it is clear that much of the SDK and documentation is still not complete. In the end I had to get in touch directly with the Vista UAC team at Microsoft in order to make any real progress. It is clear that there is still a lot of work to be done and I just couldn’t see Vista being ready by the end of the year. Vista makes a complete paradigm shift in security by restricting default user accounts to standard level privileges. The discussion in the developer newsgroups makes it painfully clear that this will have huge implications on many existing applications and the way Windows software has been written in the past.

Delaying the general availability of Vista until 2007 has got to be a good thing. It is better that Microsoft concentrate on quality and get things working properly than rush the release out. Developers also need time to assess the implications and work on compatibility changes and for many this delayed release will cause a sigh of relief.

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:

rdp1.JPG

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:

rdp2.JPG

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

Alpine Air

Filed under: General — Marcus Tettmar @ 1:02 pm

Thought I’d share this image. This was the view I had on Monday morning from the Alps in the Portes du Soleil. I took Friday and Monday off for a long weekend snowboarding in the French and Swiss Alps. The conditions were the best I have seen in six years and we had four incredible days.

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 9, 2006

Macro Scheduler Success Story – ISBVI

Filed under: Success Stories, Uncategorized — Marcus Tettmar @ 6:48 am

By Jeff Frownfelter.

Background

My name is Jeff Frownfelter, and I am the Technology Coordinator for Indiana School for the Blind and Visually Impaired. I was employed here in 2003 for the purpose of deploying and supporting new technology for use by the students and faculty. I have worked in the IT field since 1985, supporting and managing within various types of organizations, including primarily Health Care and technology-related publications. My experience is balanced between technology and software development, although I started out as a hard-core programmer like many during the technology rush of the mid 80’s.

Established in 1847, The Indiana School for the Blind and Visually Impaired is accredited by state and national certifying organizations. The school, which has an enrollment of approximately 179 students, offers pre-school through high school programs and related services, free of charge on a residential or day school basis, to the young people of Indiana who are blind and visually impaired.

The school provides students with instruction in the same coursework required of all school-aged children in Indiana. Specialized classes include orientation and mobility, adaptive physical education, independent living skills, vocational education, music instruction, Braille and specially adapted computer technology. Also available are experiences and opportunities to participate in recreational activities, on and off campus jobs, band, chorus, piano, scouting, creative dance, and ham radio, as well as involvement in competitive speech, track and field, wrestling, cheerleading and swimming.

After graduation, students enter the work force or continue their education at colleges or technical schools. Graduates of ISBVI are involved in such careers as law, education, computer technology, business sales, manufacturing, supportive employment and health services.

The Challenge – Life Before Macro Scheduler

Software, networked computers, and other devices here must be accessible, suited for students with varying levels of vision and other conditions. Computers here are initially installed from an image, but they must quickly be customized to suit the special needs of individuals or groups in terms of software. Re-imaging to perform installs and updates does not work well here for that reason, as that type of process AND the wide ratio of support personnel to devices is too unmanageable and creates more disruption than what is simply accomplished through updates.

The challenge is that much of the specialized software used here does not support unattended / quiet / over-the-network installations. It was originally necessary to manually install the software at each workstation. This was a huge time burner of course.

The Solution – Life After Macro Scheduler

Using Macro Scheduler and its compiler, I have been able to produce scripts and executables that I can include OVER needy software installations. These executables are applied to the standard startup scripts, and they are able to execute without logging into the workstation. Some of these OVER-installs use Macro Scheduler’s robust scripting to go as far as validate a proper installation, re-stage a retry after reboot (if needed), and even enter the application after install in order to modify the defaults directly.

We are also using Macro Scheduler to help facilitate the transition of our email systems from Groupware to Microsoft Exchange. Scripts manage the changes that need to be made to the email profiles. We even have Macro Scheduler scripts which collect POP3 email, parse the emails, make changes to the headers and insert them into the new email system. These scripts are very powerful and extremely reliable and run without problems continuously for days on end.

The Benefits of Macro Scheduler

A good example of how Macro Scheduler makes a positive impact on time here … So many bridges that otherwise would have been difficult (or impossible) to build during a major deployment this past summer, involving numerous software updates / additions AND user assistance upon first-time use –- Within a few weeks, a temporary tech was able to complete the deployment on all of our workstations. Prior to the automation courtesy of Macro Scheduler, 2 extra months or sets of hands would have been necessary. Likewise, this possibly would have been the case when staff returned from summer break. Difficulties were anticipated to be far greater without Macro Scheduler. Processes and wizards created with Macro Scheduler helped many users self-start with email and other applications that were affected.

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.

March 6, 2006

« Newer Posts — Older Posts »