Scripts

Scripts represent powerful and handy administrative facilities that allow automating most routine tasks. As a matter of fact, most system administrators use logon and logoff scripts, which represent batch (BAT) or executable (EXE) files that run any time the user logs on or off from any of the networked workstations. Such scripts may contain operating system commands (for example, the ones that restore network connections or run applications), specify environment variables, such as PATH or TEMP, and many more.

Starting with Windows 2000, several enhancements have been added to this area. To remain compatible with earlier Windows NT versions, Windows 2000, Windows XP, and Windows Server 2003 continue to keep the logon script that was used in Microsoft Windows NT 4.0. As you remember, already in Windows NT 4.0 logon scripts were assigned to individual user accounts. In Windows 2000, Windows XP, and Windows Server 2003, you assign logon scripts to individual users by typing the path to the logon script file in the Logon script field of the Profile tab in the UserName Properties dialog (see Fig. 10.11).

Note 

For local users in Workgroup environment, use Computer Management MMC snap-in for this purpose. When your computer joins to an Active Directory domain, the same task is performed on domain controllers using Active Directory Users and Computers MMC snap-in.

When a user logs on with an account to which a logon script has been assigned (i.e., a path to the logon script for the user account appears in the Logon script field), the server locates and runs the script. Note that the entry in the Logon script box only specifies the file name (and optionally the relative path) of the logon script. The actual logon script is located on the server.

Windows 2000/XP and Windows Server 2003, in addition, provide a set of policy-driven scripts, including user logon, user logoff, computer startup, and computer shutdown scripts, which you can manage using the Group Policy snap-in (Fig. 10.14). In contrast to logon scripts assigned at the Profile tab of the UserName Properties window, which apply to individual users only, scripts assigned using the Group Policy apply to all the users and computers for which a particular Group Policy object applies.

Figure 10.14: In addition to Logon/Logoff, Windows 2000/XP and products of the Windows Server 2003 family provide Startup/Shutdown scripts

Note 

Microsoft assumes that on a Windows 2000 Server or in a Windows Server 2003 environment, Group Policy is the administrator's primary tool for defining and controlling how programs, network resources, and the operating system behave for users and computers in an organization. In an Active Directory environment, Group Policy is applied to users or computers on the basis of their membership in sites, domains, or organizational units. More information on Group Policy will be provided later in this chapter.

To run the Group Policy MMC snap-in, click Start, select the Run command, and type gpedit.msc into the Open field.

Note 

You must be an administrator to add Group Policy to a Microsoft Management Console (MMC) and to use Group Policy in a saved console.

The Group Policy snap-in includes the following two extensions for script deployment:

• Scripts (Startup/Shutdown). After opening the Group Policy MMC snap-in, you can find these policies under Local Computer Policy | Computer Configuration | Windows Settings. Use this extension to specify the scripts that run when you start up and shut down the computer. To assign a startup or shutdown script, navigate to the Scripts (Startup/Shutdown) node in the console tree, go to the right pane and then double-click the script that you want to configure. Note that the script that you assign using this method will run on the LocalSystem account.

• Scripts (Logon/Logoff). Use this extension to specify the scripts that run when a user logs on or off the computer. To configure the user logon and logoff scripts, start the Group Policy snap-in, expand Local Computer Policy | User Configuration | Windows Settings, then click Scripts (Logon/Logoff), go to the right pane and double-click the script that you want to configure. These scripts run on the User account and not on the Administrator account.

Also starting with Windows 2000, yet another improvement was made in the scripting area - Windows Script Host (WSH) 2.0 - a language-independent scripting host that includes support for Microsoft Visual Basic Scripting Edition (VBScript) and JScript scripting engines. WSH 2.0 is capable of creating simple but flexible and powerful scripts to automate network administration. Because WSH is language-independent, you're free to select any scripting language you prefer: Visual Basic Scripting Edition (VBScript), JScript, and Perl. WSH also supports COM, allowing you to enjoy the advantages of new technologies such as Windows Management Instrumentation (WMI) and Active Directory Services Interface (ADSI). Since Windows 2000 and its successors include Windows Script Host (WSH), all above-mentioned scripts can use it. This means that you can run the script when you click it on the Windows desktop or when you type the name of the script at the command prompt, and then press <Enter>.

Using WSH in Logon Scripts

We won't dive into the details here; instead, let's look at a small example of the logon script which edits the registry (after all, this is a book on the registry). Most end users are afraid of registry editing procedures. Because of this, you can write a small logon script for these users that customizes the system registry. WSH provides a convenient and easy technique for manipulating the registry using the following methods: regRead, regWrite, and regDelete.

An example of the code provided below changes the proxy settings stored in the registry under HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer. First of all, you need to read these settings using the regRead method. Then, using the regWrite method, you can overwrite the existing value (for example, replace the existing value by NEWPROXY:80). Finally, you need to make sure that the changes you've introduced are correct. This is done using the regRead method:

    ...    sub regProxy       prefix = _          "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\"          WScript.Echo "Old ProxyServer settings:" & wshShell.regRead(prefix & _           "ProxyServer")       wshShell.regWrite prefix & "ProxyServer", "MYPROXY:80"          WScript.Echo "New ProxyServer settings:" & wshShell.regRead(prefix & _            "ProxyServer")    end sub    ...