Logon Scripts

Logon scripts in Terminal Server environments are no different from those in any other type of environment—they are simply batch files that run whenever a user logs on to the server. As with other components of Terminal Server environments, there are several different ways to use logon scripts and some are more effective than others. Before discussing how logon scripts are used, let's take a look at how they work.

How Logon and Logoff Scripts Work

Both logon and logoff scripts are batch files that execute when a user logs on or logs off of a Terminal Server. These scripts can use system environment variables and can call other scripts and executables.

With logon scripts, you can assign a batch file to run when certain users log on or when a certain Terminal Server computer is used. They allow you to influence certain aspects of a user's environment without taking full control of it (as when policies or profiles are used). Terminal Server logon scripts can be used to:

• Define and map a user's home folder (if this is not done automatically).

• Set up an application's environment in the user's home folder, by creating subdirectories and copying the necessary configuration files from a template directory.

• Modify the user's profile/registry.

• Verify or set permissions in a home folder.

• Start background processes.

• Configure and prepare any Windows components for use.

• Map network drives.

• Create icons and shortcuts for the user.

• Map printers.

Logoff Scripts

In addition to logon scripts, you can configure logoff scripts that run whenever a user logs off of the Terminal Server. These scripts serve several purposes, including:

• Deletion of unwanted temporary folders.

• Backup of important files.

• Copying of files to network locations.

Why should you care about logon script design?

In most Terminal Server environments, logon scripts are used in addition to profiles and policies to create the user environment. If your system requires logon scripts, then you will need to use them. When designing logon scripts, the decisions you must make relate more to how the logon scripts are implemented than to what they do when they run.

If you don't carefully consider all logon script options available, you could limit the flexibility within your environment. For example, some logon script languages are more flexible than others, allowing more powerful scripts to be created.

What are the logon script options?

When designing logon scripts, you'll most likely spend most of your time writing the script itself, but there are a few decisions that you can make to help implement your scripts. Make these decisions by answering the following questions:

• What script language will be used?

• How will the scripts be launched?

• Will you use the same script on all of your servers?

Script Language

There are hundreds of languages available for creating logon scripts with few differences between them. In this section, we'll focus on two of the most popular scripting languages. If you have another preferred language, use it with Terminal Server.

The two scripting languages that we will mention here are Windows batch scripts and Kixtart scripts.

Windows Batch Scripts

Windows batch scripts are regular BAT or CMD files. Batch scripts are the most popular and easiest to use of all the available scripting languages, mainly because this is the script language that most of us have been using for fifteen years.

With Windows batch scripts, you can use system environment variables and create conditional logic. There are several advanced features built into this powerful scripting language. In many environments, you'll be able to do everything that you need to with Windows batch scripts. If there is anything that you can't do with the native scripting language, you can always call another commandline utility from your script.

Advantages of Windows Batch Scripts

• No third-party interpreter is needed.

• Scripts run in their own native language without needing to be compiled.

• Everyone knows how to write batch files.

Disadvantages of Windows Batch Scripts

• Limited native advanced features

Kixtart scripts

The Kixtart scripting language and interpreter is a free script environment originally included in Windows NT Resource Kits. (You can download the Kixtart utilities for free from www.kixtart.org.) Kixtart scripts are more powerful and flexible than batch scripts but are written in their own proprietary scripting language. Many administrators use Kixtart scripts for advanced features, such as the ability to conditionally branch based on a logged-on user's group membership.

Advantages of Kixtart Scripts

• More advanced than batch scripts.

Disadvantages of Kixtart Scripts

• Written in a proprietary language.

• Requires the kix.exe script player

Launching Scripts

After you write your logon scripts, you'll need to decide how the scripts will be launched. In the past this was easy (there was only one option). Today, there are five different methods that can be used to launch a logon script for a given user. Some of these methods apply to all users that log on to a particular computer. Other methods apply to a particular user and follow that user to all computers. The five methods are:

• User's Domain or Active Directory account object properties.

• Group policy.

• Startup folder.

• Launch scripts via the registry.

Method 1. User's Domain / AD Account Properties

Most people configure logon scripts on a "per user" basis as part of the user's domain or Active Directory account configuration. This is the standard way of configuring logon scripts, and scripts configured in this manner will run when-ever the user logs on to any computer in the domain. It's easy to apply different scripts to different users using this method.

On the other hand, a disadvantage of applying scripts this way is that they run no matter where the user logs in—whether or not the system is a Terminal Server. This is not usually considered a show-stopper, as it's relatively straight-forward to build intelligence into a script to detect whether or not it's running on a Terminal Server.

Advantages of Scripts via Users' Domain Account Properties

• Easy to set up.

• Scripts are automatically replicated between domain controllers (via the Netlogon$ shares).

• "Standard" way of configuring scripts.

• Different scripts can be applied to different users.

Disadvantages of Scripts via Users' Domain Account Properties

• No way to prevent a script from running when a user logs on.

Procedure for Scripts via Users' Domain Account Properties

In Windows Active Directory environments, logon scripts are configured through the MMC (User properties | Profile Tab | Logon Script).

Method 2. Group Policy

Group policy objects can contain logon and logoff scripts (in addition to computer startup / shutdown scripts) that are executed wherever the policy is applied. By using group policy, it is possible for you to "layer" scripts on the user, with different scripts applying at the site, domain, and OU levels. If a user is part of an OU structure several containers deep, it's possible to apply different logon and logoff scripts to each OU in the layer. All of the scripts will run for each user.

This method, when used in conjunction with the Group Policy Loopback processing mode is a great way to ensure that the script only runs when the user logs on to a Terminal Server.

Advantages of Launching Scripts via Group Policy

• Each group policy can have its own script, allowing for layering of scripts.

• Scripts (via policies) can be applied to specific OUs.

Disadvantages of Launching Scripts via Group Policy

• Requires Active Directory.

Procedure for Launching Scripts via Group Policy

Add the script names to the appropriate group policy via the group policy MMC snap-in (User Configuration | Windows Settings | Scripts).

Method 3. Startup Folder

The "Startup" folder in a server's Start Menu contains programs that are run automatically when a user logs on. There are two startup folders that can be used. The first is in the "all users" profile. Logon scripts or application shortcuts placed in this folder are executed by every user when she logs on. The second startup folder location is unique for each user. Any scripts stored in the "Startup" folder in the user's profile will execute every time the user logs on. If the user has a roaming profile and the scripts are stored in the "Startup" folder of that profile, the scripts will execute on any server where her profile is applied.

Of course these scripts only run once the user's environment is completely loaded. This sometimes leads to problems when scripts are modifying applications and users are trying to launch those same applications.

Advantages of Launching Scripts via the Startup Folder

• Different scripts can be configured for different users.

• If Terminal Server roaming profiles are used, you can easily create a logon script that only runs in Terminal Server environments.

• Each user can have multiple logon scripts.

• User-specific and server-specific logon scripts can be easily combined.

Disadvantages of Launching Scripts via the Startup Folder

• If the profile doesn't load, the script won't run.

• Script sometimes runs after the user is already opening applications.

Procedure for Launching Scripts via the Startup Folder

To launch logon scripts via a startup folder, all you need to do is copy the script into the appropriate startup folder. For "all users," the folder is unique on each server (Local Profile Root\All Users\Start Menu\Programs\Startup). For specific users, the logon script must be copied to their master profile locations (User Profile Root\Start Menu\Programs\Startup).

When you put a logon script in the startup folder, you might wonder whether you should copy in the actual script or shortcuts to the script. Even though "best practices" dictate that you should only place shortcuts in the Start Menu, in this case you should put the entire script in the startup folder. Even the longest logon scripts are relatively small in size, and it's much easier to manage if the actual scripts are in the startup folder.

Method 4. Launch Scripts via the Registry

Another method by which to launch logon and logoff scripts is to add entries to your Terminal Server's registry. Every server has a registry key that specifies programs that are executed when the server is booted or when users log on. Adding your logon scripts to the list of programs executed when a user logs on is an easy and effective way to establish a logon script for all users on a particular server.

Advantages of Launching Scripts via the Registry

• Script always runs, without exception.

• No dependency on profiles or network drives.

Disadvantages of Launching Scripts via the Registry

• Must be configured manually on every server.

Procedure for Launching Scripts via the Registry

The logon and logoff programs that are run when users log on or off are specified in the following locations:

Logon Script

Key: HKLM\Software\Microsoft\Windows\Current Version\Run

Value: Free-form name of your script.

Type: REG_SZ

Data: Full path and executable of script. Each script requires its own "value" entry.

Logoff Script

Key: HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

Value: LogoffApp

Type: REG_SZ

Data: List of applications that are to be run, separated by commas.

Launching Different Scripts on Different Servers

Each of the four methods of launching logon scripts has its own advantages and disadvantages. In large environments, you'll probably need to be able to launch different scripts for different groups of servers. If you're using Active Directory, you can simply apply scripts via GPOs. However, if you're not using AD, there's a simple solution that still allows you to launch different scripts on different servers.

Add a line to your logon script that checks to see if a certain condition is true. If it is, the script will run. If not, part of the script can be skipped. This allows you to conveniently configure a logon script to run on all servers that is smart enough to know where it's running and which parts should run.

An easy way to accomplish this is to create a logon script that checks for the presence of a flag file on the server. If the flag file is present, the script is executed. If not, the script is aborted. Simply copy the empty flag file to the servers where you want your script to run. For example, you might add the following line of code to your logon script:

 if exist %systemroot%\yourflagfile.txt goto exit 

This would cause the script to exit if yourflagfile.txt was found on the server.

Real-World Logon Script Usage

Most new Terminal Server administrators don't focus on logon scripts for user customization. Instead, they often focus on the default profile that users will use and the policies in place to secure the desktop. Unfortunately, one problem that's often overlooked when using a preconfigured default profile for configuring the environment is that new changes will have to be added to that profile and existing user profiles will have to be deleted to allow the change to take effect.

Most experienced Terminal Server administrators use logon script to customize their user environment. These scripts (in any language) often accomplish some common tasks, most frequently:

• E-mail or E-mail profile configuration.

• Modification of per-user registry entries for specific applications.

• Creation of network printers.

• Copying of application files to the user's home folder.

• Configuration of Windows desktop settings.

Let's assume that you already have a 10-server load-balanced cluster deployed. The cluster hosts Office XP (including Outlook) and a document management software package. Now, imagine that a new update has been tested for the document management package, but it will require that several registry entries be changed for each user. What's the best way to go about this?

Of course if you're using roaming profiles, you could make the change to the default user profile and then delete all of your users' current profiles, but this would cause the loss of all your users' personalized settings in Microsoft Office.

A better option in this case would be to write a script that modifies the required registry keys at logon, leaving the rest of each user's profile intact while still satisfying the requirements for the software upgrade.

Considerations when Designing Logon Scripts

When you begin to design your logon scripts and decide how they will be invoked, there are two questions to consider:

• Do you need scripts to run on a "per-user," "per-server," or "perapplication" basis?

• Do you need different scripts to run on different servers, depending on which the script is running on?

The answer to the first question will help you determine how to launch the logon scripts. Figure 6.12 provides a snapshot of which script launching methods can be used in which situations.

Method	Per-User	Per-Server
Domain Account	•
GPO	•	•
Startup Folder	•	•
Registry		•

Figure 6.12: The various methods that can be used to launch scripts

The answer to the second question will help you determine what type of logic you will need to include in your logon scripts. With that, you should have all the information you need to design effective and efficient logon scripts, in turn making your Terminal Server environment easy to manage.