Preprogrammed

Various kinds of scripts are available for automating tasks in Windows. These scripts start automatically when you log on or log off and when you boot up or shut down the computer. Microsoft offers various options for integrating scripts into Group Policy, which makes the administration of computers extremely flexible. In this article, I will show you how to make life easier with Windows scripts.

One example of centralized script usage is to assign Active Directory (AD) users logon scripts that a computer executes when the employee logs on. In many cases, the AD user account settings are used for this purpose. The scripts can also be quickly and easily integrated into Group Policy without any big changes. This allows you to split a large, long, and complex logon script into several small scripts and execute them quickly and easily.

In AD, there are basically five ways to assign scripts to your users or computers. You can also mix several script types and simultaneously store several scripts. Windows computers then run all these scripts in your specified order. The following variants are available for automatically executing commands when users log on or at computer startup:

1. The classic logon script is entered in the Profile properties and executes in a command prompt window that you can partially see. This script has nothing to do with group policies but can be used in parallel. However, it is best to integrate such logon scripts into the Group Policy.

2. Logon scripts in the Group Policy for users start when a user logs in. Normally, the user does not see the execution of the script because the window is hidden.

3. Logoff scripts in the user's Group Policy are executed when a user logs off.

4. User-independent scripts in Group Policy are executed at boot time in the background before a user logs on to the computer.

5. User-independent scripts in Group Policy run when the machine is shut down or restarted after the user logs off.

Classic Logon Scripts

The classic logon script that executes programs and commands in a batch file is specified in the Profile tab in the user's Properties dialog. At this point, you also save the local user profile on a share. For the scripts to launch when users log on, you need to store the files and programs that should call the scripts in the NETLOGON share on the domain controllers (DCs). This is not necessary when integrating scripts into Group Policy, because a copy of the script file is created in and replicated with the Group Policy.

When you copy a script into the NETLOGON share of a DC, it is automatically replicated to the other DCs by the File Replication Service (FRS). This process works independently of Group Policy and increases the probability of errors. Check the process or copy the script manually if replication is not automatic.

The NETLOGON share's local storage location is the \Windows\SYSVOL\sysvol\<domain_name>\scripts folder. The scripts can be either simple batch files, variants such as KiXtart [1] or AutoIt [2], or other types of script files. Windows only needs to be able to run the scripts and recognize the appropriate extension.

Classic logon scripts run visibly when a user logs on to the computer. The user sees the sequence of events, the commands, possibly stored passwords, and more. Users can also close the window and stop the script, which is a disadvantage compared with Group Policy integration. Traditional logon scripts do not allow you to write scripts that a computer already executes at startup.

Integrating Scripts into Group Policies

In AD, you can use policies that specify scripts in addition to or instead of the classic scripts at logon/logoff and at computer startup/shutdown. All variants can be used in parallel. This has the advantage that such scripts can also be assigned to organizational units (OUs) or entire domains. Because you can also assign different group policies for different containers in AD, you can assign your own scripts to the containers. In this case, complex queries are not required in the scripts, making them much smaller. You then store the scripts in the group policies at the following locations:

• Computer startup and shutdown scripts: Computer Configuration | Policies | Windows Settings | Scripts .
• User logon and logoff scripts: User Configuration | Policies | Windows Settings | Scripts .

Processing scripts using group policies provides more flexibility. This also includes traditional logon scripts that you no longer need to trigger via user profile properties. The scripts in a group policy run invisibly in the background. This way, users do not notice the scripts, even if conventional BAT or CMD files are used. To use scripts in group policies, create the appropriate Group Policy and associate it with the domain or OUs you want to use. The procedure corresponds to the handling of conventional Group Policy. Open the Group Policy Editor and navigate to the area where you want to store the script, such as Computer Configuration or User Configuration . Group Policy can handle scripts for users and computers simultaneously.

Double-click on the respective script entry (i.e., Logon , Logoff , Startup , or Shutdown ). In addition to conventional scripts, PowerShell scripts can also be connected here. You can mix PowerShell scripts with batch files, and even with other variants such as EXE files. If you click the Views button, an Explorer window will open with the Group Policy directory, where the script files that run in the group policies must be saved. An example of this is:

\\contoso.int\sysvol\contoso.int\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\Scripts\Startup

Then, copy your script file to this open folder. Now click the Add button and select the script (Figure 1). It is then displayed in the window. You can also run multiple scripts in succession or set special parameters to run with the script.

Figure 1: Scripts can be integrated into the traditional group policy management console.

Combine and Execute in Parallel

A combination of classic scripts and group policy scripts is also possible, as well as a combination of scripts in different group policies for computers and users, which means that some scripts can be stored and run in the properties of user accounts, and others can run in different places in the group policies. It is also not a problem if the Group Policy scripts are inherited from parent OUs and start more scripts in the subordinate OUs.

You can therefore combine all possible configurations. If companies work with classic and Group Policy scripts, both run in parallel. You should consider this fact in your scripts if, for example, dependencies exist. Group Policy scripts usually run before the classic logon scripts (Figure 2).

Figure 2: In the Local Group Policy Editor, you can specify settings to manage the scripts.