Lots of people are saying Vista won’t make it for the current launch Schedule. Robert McLaws at Longhorn Blogs says Vista Needs More Time. Scoble agrees. I say get the product right, even if it means a delay and a short term hit on stock price. This is a major new operating system after all.

Great post by Jesper Johansson, Senior Security Strategist at Microsoft, on Vista security and why beta testers should not disable User Account Control just yet: http://tinyurl.com/j5z7x. Worth a read.

If you’ve been playing with the Vista betas recently you’ll have noticed how often it asks for your permission to perform admin level functions. By default Vista runs all users as ordinary level users (even if you’re logged in as an Admin) and asks for permission via “Elevation Prompts” every time an admin function is required. All fine and dandy - and much more secure - in theory, but many people have commented on how “chatty” this makes Vista. Early betas were worse and just copying a file can be really quite annoying.

Well, Steve Hiskey of the Windows Security Core Group over at Microsoft has written about how they intend to reduce elevation prompts and how they are working hard, both internally and with external ISVs, to make Vista a little less “noisy”. Well worth a read if you’re concerned about all those pesky elevation prompts, or if you’re writing applications for Vista and want to help improve things.

The UAC team have quite a challenging role - to make using Vista more secure without making it more cumbersome and more difficult to use than XP. They still have a few challenges ahead of them, but I can vouch for their commitment and support for independent software vendors as Steve and his team were extremely supportive in helping us ensure Macro Scheduler could record properly in Vista. So if you’re beta testing Windows Vista be sure to help them out via their blog.

Reducing Elevation Prompts in RC1

The Windows Vista Customer Preview Program was launched yesterday evening making Vista beta 2 available to everyone. Until now it has been confined to members of the Technical Beta Program and MSDN subscribers. Now anyone can download it or order a copy on DVD. So if you are wanting to try Vista out now is your chance.

http://www.microsoft.com/windowsvista/getready/preview.mspx

So Vista Beta 2 was made available to MSDN subscribers this week. We installed a copy yesterday and my first impressions are good. It installed quickly with the minimum of fuss and the performance is good - it seems pretty quick. Beta 1 was agonisingly slow so it’s good to note that beta 2 is faster. No doubt beta 1 had lots of debug/diagnostic code in it which was slowing things up, and they’ve probably worked on improving performance generally since beta 1. Macro Scheduler 8.0.3 runs nicely in beta 2, as I expected

Now that beta 2 is here things should start to settle down, documentation will hopefully improve, and more developers will start working on Vista-izing their software. So things should become clearer and we can hopefully get a better idea on what it will take to create a Vista version of AutoLogon. Watch this space.

As you know we have been working hard on ensuring Macro Scheduler is compatible with Vista and our latest 8.0.2 maintenance release is built with support for Vista. But what about other applications?

Well, Microsoft’s “Application Experience Team” have started their own blog to provide resources for testing application compatibility and “To help make the Application Compatibility process manageable and successful for you, and help us learn about your experiences”. Their first post links to Microsoft Connect where you can sign up for the Application Compatibility Toolkit V5.0 Beta program to receive tools to test your existing applications for Vista compatibility.

Check out All Things AppCompat.

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.

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.

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 …

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.