Getting caught out by your logon script

Whenever I go onsite with a customer to start a Windows Vista deployment project I always like to discuss with them the issues that we will be having during the project.  I do this so that, together, we can try and avoid having the issues in the first place.  Most of the issues the customer is already aware of as they have been testing Windows Vista in a laboratory environment for a while; however, there is one issue that nearly always catches them unaware and gives them major headaches, their logon script.

This is often one of the biggest problems that a company will have when trying to deploy Windows Vista.  The reason that most people do not notice that the logon script does not work on Windows Vista is because they have done their testing only in a laboratory environment where the logon script does not exist.

Let's look at a hypothetical example.  Contoso developed a MS-DOS based logon script when they first rolled out their systems on Windows NT 4.0.  When Windows 2000 was realised, they made some amendments and added more code to the script in order for it to work on the new platform.  When Windows XP was released, they had to tweak it again and add substantially more code in order to be able to migrate it to the Windows XP platform.  Because the script has been extended each time they rolled out a new OS, it is now a monster of a script with almost 2000 lines of code.

Now, based on their past experience, they have assumed that they will just need to tweak it and probably add some more code so that it works with Windows Vista, consequently, they have not actually gotten around to testing the script yet, nor assign the resources to this task.  Big mistake, because they haven't realised that the chance of the script working 100% on Windows Vista is almost 0.

Why?  The new security model that Windows Vista uses, that's why.  Let me give an example.  Contoso has an application that is vital to their business.  It is an application that requires certain keys to exist in the HKEY_CURRENT_USER section of the registry, and without those keys the application will not start.  Because Contoso users do not have roaming profiles, the IT team added the following line to their logon script to ensure that this application always works, regardless of which computer the user logs on to:

regedit.exe /s %logonserver%\vitalapp.reg

Consequently, when the user logs on the registry file imports the required keys into the registry and the application works correctly, and because this is in the logon script the process is invisible to the end user.  However, if the same script is run on Windows Vista, the following window will appear during the execution of the logon script:

The famous (or infamous...?) User Account Control (UAC) window

This window will appear because the resource regedit.exe is a protected file that requires administrative rights to be able to run it.  Unfortunately for Contoso, their logon script imports 12 different registry files which means that their logon script causes the UAC prompt to appear 12 times.

There are several ways to stop this message appearing, but they all reduce the overall level of security of the operating system (for example, you could disable UAC or give all users admin rights).

But don't panic!  There are plenty of solutions that you can use to solve these issues whilst maintaining the UAC feature and the extra security benefits that it gives.  The method I also recommend to customers is to use custom ADM files to create the registry keys, see here for a good guide on how to do it.  That way, every time the user logs on and receives their group policy configuration, the registry key will be created.  And, because it runs in a different context to the user, it will have enough permissions in the registry to create the keys without invoking the UAC window.

If you are considering, or even if you have already started, deploying Windows Vista in your business environment, I strongly recommend that you test your logon script thoroughly and as soon as possible on Windows Vista.  The last thing you want is to have to put the deployment on hold when the problems start appearing.

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain