Windows 2000 Script Policies

Automate logon and logoff by implementing script policies

In Windows 2000 (Win2K), Microsoft includes a helpful new script-related feature: script policies. Win2K script policies are a component of the Group Policy technology in Win2K. Group Policy provides you with the ability to define and control multiple computer and user environments. With script policies, you can develop, define, and run scripts based on key system events. For example, you can create startup and shutdown scripts, and you can easily assign these scripts to one or more computer objects. Likewise, you can create and assign both logon and logoff scripts to one or more user objects.

Because script policies are a component of Group Policy, the key to successfully implementing script policies begins with a good understanding of Group Policy. Although this article isn't about Group Policy, I provide some Group Policy information so that you can understand the role Group Policy plays in script policies. For more information about Group Policy, see Darren Mar-Elia, "Introducing Group Policy," September 1999.

Group Policy comes in two flavors: local computer policy and the Active Directory (AD)-integrated Group Policy. Of the two types, local computer policy is the simpler type to understand. However, local computer policy is the most difficult type to maintain in large environments because you perform configuration on a per-machine basis. Local computer policy is a per-machine policy definition that you configure using the Microsoft Management Console (MMC) Group Policy snap-in Gpedit.msc, which you find in the %systemroot%system32 directory. By default, the hidden %systemroot%system32grouppolicy folder stores and maintains the local computer policy configuration data. In the Group Policy folder, the machinescriptsstartup, machinescriptsshutdown, userscriptslogon, and userscriptslogoff folders store the scripts that you configure as part of the script policy's local computer policy.

The second and more powerful flavor of Group Policy leverages AD. In this scenario, you configure Group Policy for a site, domain, or organizational unit (OU). By default, Group Policy controls all computer and user objects in the site, domain, or OU. Because the script policy component is part of Group Policy, you apply the script policy settings to all computer or user objects in the site, domain, or OU. In addition, the Group Policy inheritance settings also affect the script policy settings on child computer or user objects in the site, domain, or OU. When you want to apply policy settings to objects in a tree container or branch, you can use ACLs to restrict the targeted computer or user objects that Group Policy affects.

You perform Group Policy configuration for an AD site using the Active Directory Sites and Services MMC snap-in Dssite.msc. You perform Group Policy configuration for an AD domain or OU using the Active Directory Users and Computers MMC snap-in Dsa.msc. In the %systemroot%sysvolsysvol domain.compoliciesGUID folder, the machinescriptsstartup, machinescriptsshutdown, userscriptslogon, and userscriptslogoff folders store the scripts that you configure as part of Group Policy. (Domain.com is the domain name that you applied Group Policy to. The globally unique ID (GUID) is the Group Policy GUID generated at the time you created Group Policy.) Let's look at the types of scripts you can create using script policies.

Script Types
In Win2K Group Policy, Microsoft has introduced four new script types. These script types are startup, shutdown, logon, and logoff. Startup and shutdown scripts are part of the Group Policy computer configuration. You run startup and shutdown scripts on each computer that you apply the script policy to--­either directly or through Group Policy inheritance. Logon and logoff scripts are part of the Group Policy user configuration. Group Policy logon and logoff scripts provide a mechanism through which you can define and apply common scripts to multiple users. The Group Policy logon script isn't related to the logon script defined as part of a user's profile. Unlike the one-to-one relationship between a user account and the profile-based logon script, Group Policy logon scripts affect multiple user objects in the site, domain, or OU container (and child containers) that you apply Group Policy to. Any user in the configured container performing an interactive logon will trigger Group Policy logon scripts.

You can write script policy scripts in any language the OS supports. For example, you can continue to use batch files or write Windows Scripting Host (WSH) scripts in VBScript or JScript. You can also use the new Extensible Markup Language (XML)-based Windows Script (.ws) file type.

The execution order for script policies is straightforward. The computer runs startup scripts when it starts and shutdown scripts when it shuts down. Startup scripts run after the computer initializes network connections, and shutdown scripts run before the computer deletes network connections. Therefore, you can access network-based resources from startup and shutdown scripts.

Logon scripts run when a configured user logs on to the computer, and logoff scripts run when the user logs off. Of course, logon scripts always run after startup scripts, and logoff scripts always run before shutdown scripts. You can also define multiple scripts for each script type, in which case the OS executes the scripts in the order the scripts appear in the Script Properties dialog box.

Implementing Script Policies
The best way to understand script policies is to try them out in your lab, so let's walk through an example. The following steps modify the Default Domain Policy definition. Make sure you have AD running and follow the steps verbatim. If you don't have AD, you can easily adapt the steps to the local computer policy.

You can now restart the machine and see the results of the script policy change. I urge you to become familiar with Group Policy in a lab setting before implementing Group Policy in your production environment. Group Policy can easily become complex and confusing without a well-thought-out and tested plan.

Exercise Caution
You need to take certain precautions when you implement script policies. The last thing you want is for a server to hang because a shutdown script fails to run to completion and exit gracefully. At a minimum, I recommend the following:

I'm excited about the depth and breadth of script-related improvements in Win2K. Script policies are certain to make the lives of many systems administrators much easier. Furthermore, because script policies are part of Group Policy, you can configure hundreds of servers as easily as you can configure one server. Win2K has even more automation-related improvements that I'll discuss in upcoming articles. You'll learn even more ways to automate tasks that you once considered unscriptable on the Windows NT platform.