A:
Group Policy Objects (GPOs) provide for computer-based startup or shutdown and user- based logon or logoff scripts. Using these scripting capabilities, you can “trap” for logoff and shutdown events and perform actions based on them. In Windows NT 4.0, I can’t tell you how many times I wanted a way to perform some action, like killing a process or running anenvironmental cleanup script, before the user ended their session either by shutting down or logging off. With Active Directory (AD)-based GPO in Windows 2000 (Win2K) and Windows XP, it is easy to do so.
GPO-based script policy can support any number of “executable” types, from DOS-style batch files to Perl scripts to Windows Script Host (WSH) scripts, and even compiled executables. This functionality provides for a lot of power in executing tasks based on these types of user-driven events. Creating startup/shutdown or logon/logoff policy is easy. After you start the Group
Deciding whether you need to use a shutdown script or a logoff script is more than just deciding when you want the script to run. Computer-based scripts run with a different security context from user-based ones. Namely, computer-based scripts run under the security context of LocalSystem, and user-based scripts run under the context of the logged on user. Thus, startup and shutdown scripts have privileges to do pretty much anything they want on the local
computer, but logon and logoff scripts are limited to what the user can do. However, because shutdown and startup scripts run in the context of LocalSystem, they cannot access other Windows resources located remotely from where they’re running. It’s important to understand that both logoff and shutdown scripts execute at the beginning of the logoff and shutdown
processes, respectively. Thus, they should have the entire environment they need to perform their tasks. However, it’s always a good idea to test your scripts first—I have found cases in which certain commands did not work because they made assumptions about the environment that were no longer valid. This scenario is especially a possibility for shutdown scripts.
You also need to be aware that shutdown and logoff scripts always run synchronously. That is, when the scripts start running, no other tasks are happening in the background that might affect the scripts proper execution. This behavior makes sense because Windows might start shutting down valuable resources required for a shutdown or logoff script to execute if those scripts were allowed to run asynchronously, as startup and logon scripts can.
If you want to enable shutdown scripts on your Win2K domain controllers, be aware of a particular twist in the way GPOs are processed on domain controllers. You will need to implement your shutdown scripts within the built-in Default Domain Controllers Policy GPO. If you try to implement shutdown scripts on domain controllers in another GPO, it will simply be ignored.
If you need to provide some kind of user dialog box within your logoff or shutdown scripts, be aware that depending upon the type of dialog box that you display, your users might not see it. For example, if you’re running a WSH script and you use the Wscript.echo method to output a dialog box for the user to confirm, the dialog box will appear only as a popup box that waits for user response if your default WSH script executable is Wscript.exe rather than Cscript.exe. If you need to show the user a dialog box for confirmation as part of your WSH script, you’re better off using the VBScript msgbox function or its equivalent in JScript.
If you expect a user to confirm a script dialog box, especially during a shutdown script, make sure that there is a good chance that a user is actually present when the script executes. If no user is present to confirm a dialog box or answer a question, the script will just sit there until the default 10 minute timeout passes, at which point the script will be killed and Windows will continue the logoff or shutdown sequence.
If, for troubleshooting purposes, you want to see the command window that is running behind the scenes when your scripts execute, you can set a computer- or user-specific administrative template policy to show verbose script execution. This policy can be found in Computer Configuration, Administrative Templates, System, Scripts (run startup scripts visible and run shutdown scripts visible) or User Configuration, Administrative Templates, System, Scripts (run logon scripts visible or run logoff scripts visible). Figure 3.15 shows how you can enable visible
Figure 3.15: Enabling verbose shutdown script execution through administrative template policy.
Enabling visible processing of scripts doesn’t change the behavior of any user dialog boxes that the scripts may generate. Visible processing simply shows the command window that is
generated by a batch file or other command shell driven script. It can be valuable for
troubleshooting if your script sends status messages to a command window during execution. Now let’s look at the process for enabling shutdown or logoff scripts. The dialog boxes for selecting and finding scripts within Group Policy are less than intuitive. Keep in mind that the script files—whether they are batch files or WSH scripts—are stored within the Group Policy Template (GPT) in SYSVOL for each GPO that references the script. So if you have a script that is implemented in 10 GPOs, the script file will be stored 10 times within the GPTs of those 10 GPOs. Figure 3.16 shows the dialog box for adding a logoff script to a GPO. All of the types of scripts supported in Group Policy follow the same pattern for adding scripts.
Figure 3.16: Viewing the dialog box for adding scripts to a GPO.
As you can see in Figure 3.16, it’s perfectly “legal” to have different types of scripts within a GPO. It’s also perfectly legal to have multiple scripts assigned to a single GPO (and, of course, a user or computer can also process multiple GPOs, leading to many scripts running during a logoff or shutdown sequence). When you have multiple scripts on a given GPO, they process in order from those higher in the list to those lower. So, with the setup that Figure 3.16 shows, shut.vbs runs first and new.bat runs second.
If you want to add a new script to the list, there are a few tricks you can use. If you click Show Files, a Windows Explorer windows will open focused on the SYSVOL folder in which the scripts are stored (see Figure 3.17).
Figure 3.17: Viewing the GPT folder within a GPO where logoff scripts are stored.
If you have scripts located in other folders, you can simply copy and paste them into this folder. That is the first step in the process. The next step is to add the new script to the list of scripts being processed by this GPO. This list is the list that you see in the top half of Figure 3.16. To add the new script, click Add, then click Browse. You will be taken to an open file dialog box focused on the GPT folder in which you just pasted your new script. From here, you simply highlight the script, and select Open to add the script to the list of those being processed by the GPO. You can also add to the script any command-line parameters, which are parameters that you might want to pass to the script as its executing (see Figure 3.18).
Figure 3.18: Adding command-line arguments for script execution.
If you haven’t already pasted the script that you want to add to the GPO into the correct folder in the GPT, there is an alternative way to call a new script. If you click Add, as before, then click Browse, you can browse the file system to locate the script that you want to add. In that case, the GPO will run the script from wherever the script is located (see Figure 3.19).
Figure 3.19: Adding a script from an alternative file location.
In the example scenario that Figure 3.19 shows, I’ve added a script called listGPO.vbs from the C:\ folder. The problem with this scenario is that that script needs to be in C:\ on every machine that the GPO processes on—or it won’t be found. An alternative approach is to reference a script located on a server share somewhere on your network and accessible from all machines.
However, keep in mind that if you take this approach, the script will not be accessible from a computer-based startup or shutdown script policy, because they are running under the
LocalSystem security context and won’t have access to network shares. I suggest that in most cases you simply copy your scripts into the GPT for that GPO so that the scripts can be
replicated with the rest of your GPOs. The only case in which it makes a lot of sense to have a script referenced from a network share is when that script changes often and is used by many different GPOs. In such a case, having to keep the script synchronized across many different GPTs would be difficult.