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.

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).

Controlling Group Policy Settings

In addition to special scripts, various settings can also be stored in the group policies that control the execution of the scripts and regulate them accordingly. The settings can also be found in the group policies. The corresponding explanations and help can be found directly in the respective setting. The following policy settings play a role:

• Computer Configuration | Policies | Administrative Templates | System | Scripts
• Computer Configuration | Policies | Administrative Templates | System | Logon
• Computer Configuration | Policies | Administrative Templates | System | Group Policy
• User Configuration | Policies | Administrative Templates | System | Scripts
• User Configuration | Policies | Administrative Templates | System | Logon

Group Policy Loopback Processing

If you use remote desktop session hosts together with Group Policy, you can store the servers in a separate OU and then enable group policies with the desired settings for these OUs. Such a scenario is not only useful for Remote Desktop Services, but it also can be used with multiple computers.

For policies used with Remote Desktop Services or multiple machines, you can enable loopback processing mode in a Group Policy. In this mode, Group Policy also applies user tree settings when the user's accounts are not stored in the OU where the policy is defined, but instead on the corresponding server or computer account. This means that you can define user settings for remote desktop servers that are only applied when users log on to the remote desktop servers, not when they log on to their local computers.

You can find this setting under Computers | Policies | Administrative Templates | System | Group Policy. Under Configure user Group Policy loopback processing mode, click on Enabled. Then, you can choose between Replace and Merge modes. If you select Replace, the policy overwrites settings already set by other policies in the same place. Merge applies the user's normal policies and user settings in the Remote Desktop Server policy. If there are conflicts, the Remote Desktop Server policy wins (Figure 3).

Security in PowerShell

To protect the computer from attacks, PowerShell offers various security features, including execution policy for scripts, which specifies whether scripts may be executed at all, whether they must at least be signed digitally, or whether all scripts are generally allowed. This also applies to execution in group policies. By default, PowerShell only processes signed scripts. If you want to write your own scripts, you must sign them digitally or adapt the policy to run them. The latter is the best way to get started with scripts. You can use the Get-ExecutionPolicy cmdlet to view the execution policy and change it with Set-ExecutionPolicy. The following options are available:

• Restricted: No scripts are allowed. This option provides security, but you cannot work with scripts.
• AllSigned: Only signed scripts are allowed.
• RemoteSigned: Scripts must be signed by a certification authority.
• Unrestricted: All scripts work. This setting is suitable for tests with login scripts. However, it also reduces the security level, which is why only signed scripts should be used in production environments.

Group Policy Log Troubleshooting

If group policies are not applied correctly on individual machines, you can troubleshoot with the free Microsoft Group Policy Log View [3] tool (Figure 4). This is especially true if scripts are not executed correctly. You can also combine the tool with group policies. Install the software on a computer you want to analyze; then, open a command line with administrator rights and change to the directory where you installed the tool. To monitor group policies, type the command:

> gplogview -o gpevents.txt

The tool analyzes all Group Policy entries and displays a text file in the directory where Group Policy errors are collected. You can also store Group Policy Log View in a logon script. It will then run on any machine that uses the logon script and give you central information about all the machines on the network that use this policy.

If you save the file with the evaluation result in a share in the logon script that you control using Group Policy, you can specifically monitor the use of the policy on multiple computers. In this case, you not only save the evaluation file in the network, but also enter the name of the evaluated computer. To do this, use the command:

> Gplogview -o \\<Server>\<Release>\%computername%-gpevent.txt

You can also create an HTML file as a report. In this case, the syntax is:

> Gplogview -h -o \\<Server>\<Release>\%computername%-gpevent.html

Remote Computers at a Glance

Administrators who remotely maintain multiple servers or networked computers often lack information about currently connected computers, such as the IP address, drive information, computer name, boot time, and more. If a user's computer needs remote maintenance, it is also helpful if they can see the name of their computer, IP address, and other information at a glance on their desktop. In many cases, administrators will find it extremely helpful if useful information can be displayed on the remote computer's desktop, without that information interfering with normal operation.

A helpful tool for this purpose is BGInfo [4] by Sysinternals (Figure 5). BGInfo can display information in different font sizes, colors, and other formats on the desktop. If you run the script as a logon script, the information is updated each time it is executed. In addition to predefined fields, you can also create your own queries and display information.

This display can be preconfigured, saved as a configuration file, and distributed to computers on the network with a script or Group Policy. The tool does not consume any system resources, but it creates a new desktop background image from the desired information at startup and then exits again. Therefore, the tool is not started during operation.

After starting BGInfo, you can configure which data you want to display in the future and save it as a configuration file. The Fields selection box shows the data you can include in the background image. Click on a field and then on <-Add to include it. Click the Custom button to define your own fields by starting a new query with New. In the new window, you are able to query environment variables, a registry value, a WMI query, or file data. However, in most cases, this is not necessary, because the standard fields already cover a lot of information.

Of course, it does not make sense to create a configuration file repeatedly or to make an individual file for each computer. For this reason, BGInfo lets you save the selected data as a BGI file with File | Save As. Then, you can start BGInfo so that it accepts this file as your configuration file and displays the selected data. To do this, simply start BGInfo with the command:

> BGInfo <name_of_the_BGI_file> /timer:0

If you do not specify a configuration file, BGInfo uses the default configuration information stored in the registry in the HKEY_CURRENT_USER\Software\Winternals\BGInfo path.

The /timer:0 option means that the BGInfo configuration window does not appear, but the information is accepted immediately. You can include this command in a logon script and capture data, such as your computer's logon time or boot time. Of course, these times are only up to date if you let BGInfo start with every boot process or every login. BGInfo does not update itself dynamically; it always uses the data it finds at startup.

After creating the new background image, BGInfo terminates again. In addition to scripts, BGInfo can also be continuously updated with task scheduling in Windows during system startup and operation. However, this only makes sense if you also display fields whose information changes during operation. In addition to the /timer option, BGInfo offers these options:

• /popup: Displays a pop-up window containing the information. This can be closed by users.
• /taskbar: Displays an icon in the taskbar's notification area next to the clock. If users click on the icon, the desired information appears exactly as in the /popup option.
• /all: Changes the data for all currently logged on users (e.g., on terminal servers). In this way, all logged on users receive the new background image.
• /log: Creates a logfile about the execution that includes errors. This option is useful if you want the tool to be started frequently during operation using the task scheduler.
• /rtf: Creates an RTF file that also contains the formatting and color for logging.

Conclusions

Microsoft allows logon scripts to be integrated into Group Policy on Windows 10 and Windows Server 2016, as well, which can facilitate many repetitive tasks. The scripts can be integrated flexibly in a myriad of ways, which opens up extensive possibilities for administrators. If you encounter any problems, the integration of additional tools for problem solving or analysis can help.