Logon and Logoff Scripts - Citrix MetaFrame XP

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 MetaFrame XP server. These scripts can use system environment variables and can call other scripts.

Logon Scripts

With logon scripts, you can assign a batch file to run when certain users log on or when a certain MetaFrame XP 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). MetaFrame XP logon scripts are used to:

• Define and map a user's home drive (if this is not done automatically).
• Set up an application's environment in the user's home directory, by creating subdirectories and copying the necessary configuration files from a template directory.
• Verify or set permissions in a home directory.
• 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 to run whenever a user logs off of the MetaFrame XP server. These scripts serve several purposes, including:

• Delete unwanted temporary folders.
• Backup important files.
• Copy files to network locations.

Why should you care about logon script design?

In most MetaFrame XP 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, not 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. However, 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. Realistically, there are few differences between the languages. In this section, we'll take a look at two of the most popular scripting languages. If you have a preferred language that you are comfortable with, use it with MetaFrame XP.

Two scripting languages that we will focus on here are Windows batch scripts and Kixtart scripts.

Windows Batch Scripts

Windows batch scripts are regular BAT or CMD scripts. 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. In fact, 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. After all, if there is anything that you can't do with the native scripting language, you can always call another command-line 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 they are written in their own proprietary scripting language. Many administrators use Kixtart scripts for their advanced features, like 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 must decide how the scripts will be launched. In the old days, this was easy (because 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 account properties.
• Group policy.
• Startup folder.
• Launch scripts via the registry.
• Launch scripts when certain applications are executed.

Method 1. User's Domain Account Properties

Most people configure logon scripts on a "per user" basis as part of the user's domain account configuration. This is the "standard" way of configuring logon scripts. Logon scripts configured in this manner will run whenever the user logs on to any computer in the domain. It's really easy to apply different scripts to different users using this method.

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 NT 4.0 environments, logon scripts are configured with User Manager for Domains (User properties | Profile Button | Logon Script). In Windows 2000 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.

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 they log 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 for the user on any server where that profile is applied.

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.

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 location (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

The last method that you can use to launch logon and logoff scripts is to add entries to your MetaFrame XP 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.

Method 5. Launch Scripts when Certain Applications are Executed

You can write application-specific scripts that create the proper environment for applications (such as setting variables, mapping drives, etc.) when the application is run.

At first, you might want to simply add the logon script components to users' standard network logon scripts. After all, you could add logic into the logon script that would detect if a user was a member of a certain group or logging onto a certain machine and then customize the environment as needed. While this is a fairly complex process, it is possible to do.

You could also create a batch file that performs all of the necessary script functions and exits with a call to the application executable. You can publish the batch file instead of the application executable.

If you have users that need to access the applications from server desktops via the Start menu, you can modify the shortcuts in the Start menu so that they point to the batch files instead of the executables. You could even change the icons back to the original ones so that the applications seem identical to the users.

Advantages of Launching Scripts when Certain Applications are Executed

• The scripts would work regardless of how the application was launched.
• The scripts will only run if the specific application is needed. Users will not need to wait while complex logon scripts are parsed every time they want to connect to a single application.
• There is no chance that an application could run without the script running first.
• Application-specific batch files could be easily managed by application owners. If a single, large logon script was needed, application owners would need to work with the logon script owner, resulting in increased complexity, the chance that something would go wrong, and the time needed to perform updates.

Disadvantages of Launching Scripts when Certain Applications are Executed

• Increased Management. Scripts have to be configured manually on all servers (although you could store the scripts in a common location and then have all the shortcuts and published applications point to the central batch file via a UNC or mapped drive).

Launching Different Scripts on Different Servers

Some methods of launching logon scripts allow you to configure different scripts on a server-by-server basis. While this allows you to have ultimate flexibility, it is difficult to manage multiple scripts across multiple servers, especially in large environments. The alternative is to launch a logon script via a method allowing you to specify one script that is executed no matter what server is used. The problem that arises is that the same script is run on every single server, even if there are particular servers where you don't want it to run. There are instances in which you might need custom scripts or custom components to run only on certain servers.

Fortunately, there's a simple solution. 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 while being smart enough to know where it's running and what 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.

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 "per-application" basis?
• Do you need different scripts to run on different MetaFrame XP servers, depending on which server the script is running?

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

• Per-User Methods of Launching Scripts
• Domain Account
• GPO
• Startup Folder
• Per-Server Methods of Launching Scripts
• GPO
• Startup Folder
• Registry
• Per-Application Methods of Launching Scripts
• Application

Figure 5.9: 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 MetaFrame XP environment easy to manage.