Windows 2000 Script Policies

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Bob Wells

Article from Windows 2000 Magazine

Automate Logon and Logoff by Implementing Script Policies

In Microsoft Windows® 2000, Microsoft includes a helpful new script-related feature called script policies. Windows 2000 script policies are a component of the Group Policy technology in Windows 2000. 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 you can understand the role Group Policy plays in script policies. For more information about Group Policy, see Darren Mar-Elia, "Application Management in NT 5.0," April 1998."

Group Policy comes in two flavors, which are local computer policy and the Active Directory®–integrated Group Policy. Of the two types, local computer policy is the simpler type to understand. However, local computer policy is also the most difficult to maintain in large environments because you perform configuration on a per-computer basis. Local computer policy is a per-computer policy definition that you configure using the Microsoft Management Console (MMC) Group Policy snap-in Gpedit.msc located in the %systemroot%\system32 directory. By default, the hidden %systemroot%\system32\grouppolicy folder stores and maintains the local computer policy configuration data. In the Group Policy folder, the \machine\scripts\startup, \machine\scripts\shutdown, \user\scripts\logon, and \user\scripts\logoff 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 Active Directory® directory service. In this scenario, you configure Group Policy for a site, domain, or organizational unit. By default, the Group Policy affects all computer and user objects in the site, domain, or organizational unit. 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 organizational unit. In addition, the Group Policy inheritance settings also affect the script policy settings on child computer or user objects in the site, domain, or organizational unit. When you want to affect 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 Active Directory site using the Active Directory Sites and Services MMC snap-in Dssite.msc. You perform Group Policy configuration for an Active Directory domain or organizational unit using the Active Directory Users and Computers MMC snap-in Dsa.msc. In the %systemroot%\sysvol\sysvol domain.com\policies\GUID folder, the \machine\scripts\startup, \machine\scripts\shutdown, \user\scripts\logon, and \user\scripts\logoff folders store the scripts that you configure as part of Group Policy. (Domain.com is the domain name to which you applied Group Policy. 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.

Script Types

In Windows 2000 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 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.

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

The execution order for script policies is straightforward. The computer runs startup scripts when it starts and shutdown scripts when it shuts down. One nice aspect of startup and shutdown scripts is that 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 operating system 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. To do this, you need to have Active Directory running and follow the steps verbatim. If you don't have Active Directory, you can easily adapt the steps to the local computer policy.

Create the startup.vbs script that Listing 1 shows and the shutdown.vbs script that Listing 2 shows. Save these scripts in the C drive's root directory.

Listing 1: startup.vbs

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

Set oShell = CreateObject("WScript.Shell") oShell.Popup "Startup Script", 10, "Group Policy - Script Policy"

Listing 2: shutdown.vbs

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

Set oShell = CreateObject("WScript.Shell") oShell.Popup "Shutdown Script", 10, "Group Policy - Script Policy"

Screen 1 Selecting Scripts (Startup/Shutdown) from Group policy

Screen 2 Adding multiple startup scripts

Open My Computer, then open the local drive (e.g., C).
Click Start, Programs, Administrative Tools, Active Directory Users and Computers to open the Active Directory Users and Computers MMC.
Right-click your domain name, then select Properties from the context menu.
Select the Group Policy tab.
Select the Default Domain Policy, then Edit. With the Default Domain Policy loaded, Group Policy Editor will display.

Screen 3 Selecting Maximum wait time for Group Policy scripts

Screen 4 Configuring the maximum wait time for Group Policy scripts
From the Default Domain Policy folder, click the plus (+) sign to expand Computer Configuration. Next, click the plus (+) sign to expand Windows Settings.
Select Scripts (Startup/Shutdown), which Screen 1 shows.
Double-click Startup.
In the Startup Properties dialog box, select Show Files.
Using My Computer, copy startup.vbs that you created in step 1 to the Default Domain Policy startup script folder. Close the startup script folder.
In the Startup Properties dialog box, click Add.
In the Add a Script dialog box, click Browse. You will see startup.vbs.
Select the script, then click Open. In the Add a Script dialog box, click OK. You will see your new script, startup.vbs, in the list of scripts, with Startup.ws and Dell610.vbs, as Screen 2 shows.
In the Startup Properties dialog box, click OK.
Repeat steps 9 through 15 for shutdown.vbs.
Close Group Policy Editor.
In the Domain Properties Dialog box, click OK, then close the MMC and My Computer.

You can now restart the computer 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 implementing 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:

Thoroughly test and debug scripts used for startup, shutdown, logon, and logoff.
Use On Error Resume Next to trap and handle errors. (For information about the On Error Resume Next statement, see "Scripting Solutions: Scripting 101, Part 2," July 1999.)
Avoid using graphical dialog boxes such as VBScript's MsgBox function. If you must display a graphical message, use the WSH Shell's Popup method with an appropriate timeout value. (For information about VBScript's MsgBox function and WSH Shell's Popup method, see "Scripting 101, Part 4," September 1999.)
Consider using the WSH //T:nn timeout option.
From the Group Policy dialog box, select Maximum wait time for Group Policy scripts as Screen 3 shows, then configure the Policy from the Maximum wait time for Group Policy scripts Properties dialog box, which Screen 4 shows.

I'm excited about the depth and breadth of script-related improvements in Windows 2000. 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. Windows 2000 has even more automation-related improvements that I'll discuss in upcoming articles. You'll learn even more ways to automate tasks, which you once considered unscriptable on the Microsoft Windows NT® platform.

About the Author

Bob Wells is a contributing editor for Windows NT Magazine, an MCSE, an MCT, and a software/systems consultant specializing in Windows NT infrastructure design and implementation. You can reach him at bobwells@winntmag.com.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as-is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English Only

Click to subscribe