Learning Windows Server 2003

6.5. Domain Group Policy

Domain-based GPs offer a much more flexible and configurable set of standards and settings for your organization than local GPs. In this section, I'll discuss the four most common methods of managing your IT assets centrally using domain GP: configuring a security standard, installing software using the IntelliMirror technology found in Windows Server 2003, redirecting folders present in the user interface to network locations, and writing and launching scripts triggered by events, such as logons and logoffs.

6.5.1. Security Settings

As discussed earlier, one of the most useful aspects of GP is its ability to control security settings and configuration from a central location across the organization. Security policy comprises three key components: restricted groups, registry settings, and filesystem settings. In this section, I'll take a look at each of them.

6.5.1.1 Restricted groups

The restricted groups option allows you to modify the current group configuration and membership on your client computers. When this policy is applied to workstations and servers, their individual group configurations are modified to match that configured inside the policy. The policy contains members and members of lists that overwrite any configuration on the target computers. For example, if you were to add the Administrator group to the policy but not add any users to the members of this group list, and then you applied the policy, Windows would remove any users currently in those groups on the client computers. However, the other facet of the policy, groups of which the added group is currently a member, is only additive: if the list is empty, no modifications are made to the client computers. Only additions are processed and changed.

Only the groups listed inside the Details window of the Restricted Groups policy branch can be modified using the policy, but it's a great way to keep individual users from modifying powerful groups on their own systems.

To modify the restricted groups' policy, do the following:

1. Inside the Group Policy Object Editor, right-click the Restricted Group branch and select Add Group from the context menu.

2. Click the Browse button, and select any group currently inside your directory. Click OK.

3. Now, right-click the newly added group, and select Security from the context menu.

4. Add the users that belong to this group to the Members of this group list, and add the groups within which this group is nested to the This group is a member of list. Use the Add button in both cases. Figure 6-23 shows this screen.

5. When you're finished, click OK to close out the boxes.

6.5.1.2 Filesystem and registry policy

You also can use GPs to configure permissions on filesystem objects and registry keys. You can set entries on the ACLs of individual files, folders, and registry keys from a central location. If you make this change at the domain-wide levelone of the few changes I recommend and endorse at that levelregistries are protected against meddling users all over the enterprise, which is definitely a benefit.

To add a registry key to be protected to a GPO, follow these steps:

1. Inside the Group Policy Object Editor, navigate through the Computer Configuration, Windows Settings, Security Settings, and Registry nodes. Right-click Registry and select Add Key from the context menu.

2. You can add three registry keys at a time, and you can selectively apply permissions to each key. Figure 6-24 shows the screen.

To add a file or folder to be protected to a GPO, follow these steps:

1. Inside the Group Policy Object Editor, navigate through the Computer Configuration, Windows Settings, Security Settings, and File System nodes. Right-click File System and select Add File from the context menu.

2. You can explore the entire directory structure and selectively assign permissions to files and folders. Figure 6-25 shows the screen.

Once you've selected the objects in question, you'll be prompted for their permissions just like I discussed in Chapter 3. After you enter the appropriate permissions, you'll be prompted to configure the properties of inheritance for these new permissions. This is shown in Figure 6-26.

If you select the configure option, you also will need to select how permissions are applied. If you choose to apply inheritable security to this file or folder and to its subfolders, the new permissions are applied to all child objects that do not have a permission or ACL entry explicitly set. This preserves your custom permissions on a tree but also automatically overwrites permissions simply inherited by default. If you choose to replace existing security for this file of older and its subfolders, you overwrite all permissions on any child folders, including those permissions explicitly set.

If you'd rather not have any of these methods used to apply permissions, simply choose the following option: Prevent the application of security policies to this file or folder and its subfolders. Doing so will make child files and folders immune to the permissions assigned by this new policy.

6.5.2. IntelliMirror: Software Installation

In my opinion, software installation is one of the coolest and most useful features of GP, and I know many administrators who agree with me. Using Microsoft's IntelliMirror technology introduced in Windows 2000, administrators using GP can distribute software applications initially, using a push or pull method, and then upgrade, redeploy, or remove that software either wholesale or when certain conditions apply. IntelliMirror also offers intelligent application repair features so that when critical files for an application deployed through IntelliMirror are corrupted or deleted, Windows takes over and fixes the problem, so the application will start and function correctly. This is a big timesaver.

You can distribute and install applications in your organization in two ways. You can assign a software package, which places a shortcut on the user's Start menu and loads the advertisement for the package into the computer's registry. Or you can publish an application, which simply places the program with the Add/Remove Programs applet in the Control Panel. The user can elect to install the software at his discretion and at a convenient time.

You also can distribute applications via the assign and publish functionality to a computer or a user. If you assign a package to a user, the application is installed on the local system the first time the user runs the software. The user-assigned applications follow a user around the network to each computer to ensure that he has all the applications he should on each computer. If you assign a package to a computer, the application is installed on that system when booted up, and the software is installed only on the computer defined in the policy. Applications don't necessarily follow a user around. If you use the publish functionality of IntelliMirror, you can publish to only a specific user because computers can't choose how and where to install software. Published applications also are not quite as robust as assigned applications and the repair functionality of published applications is limited.

6.5.2.1 Packaging software

The easiest way to publish and assign software is through the use of Microsoft Installer packages, or MSI files. Applications packaged in Installer format include a database of changes to make to files and registry keys, instructions on removing previous or outdated version of software, and strategies to install on multiple versions of Windows within one file. MSI files also allow intelligent repair functionality for use if installations become corrupted on individual computers, and their rollback function for removing or redeploying an application is useful as well. IntelliMirror and GP-based software distribution are designed to work with applications that install using an MSI package.

But all is not lost if your software isn't offered in MSI format. First, you can use the ZAP file method. You can use a .ZAP file when software isn't available with an MSI package to publish (but not assign) the application. A ZAP file is nothing more than a description of an application, its setup program, and any associated file extensions. A sample ZAP file for Adobe's Acrobat Reader 5.0 is shown here:

Line 1: [Application] Line 2: FriendlyName = Adobe Acrobat Reader 5.0 Line 3: SetupCommand = \\deploy\adobe\rp505enu.exe Line 4: DisplayVersion = 5.0 Line 5: Publisher = Adobe Corporation Line 6: URL = http://www.adobe.com Line 7: Line 8: [Ext] Line 9: PDF=

A few notes about this ZAP file: the FriendlyName section shows the application name, which will appear in the Add/Remove Programs applet within the Control Panel on the computers to which the package is published. It also contains the Setup directive, which tells Windows the network path of the file to install the package. The other tags, although offering more information on the version, manufacturer, and Internet address of the manufacturer, are optional. The Ext section lists file extensions to be associated with the program, each followed by an equals sign.

The ZAP file method has a few caveats. First and foremost, because ZAP file installations can only be published, you lose the robustness and intelligent repair features of software applications assigned to computers and users. You also can't set an application deployed via a ZAP file to install automatically on first use. In addition, a specific user must have appropriate permissions to run the package's installer executable and to access the source files for the installation. And, the installation probably is not very automated, so the process likely would require user intervention to answer prompts such as the destination directory, installation options, and so forth, which is something we all try to avoid when possible. Finally, because the installer isn't granted sweeping administrative privileges during the setup process like an MSI installer is, you might have conflicts and problems to troubleshoot with a mass package deployment.

setup /r /setup.iss

If the ZAP file method doesn't appeal to you, you can use a repacking tool, such as Veritas WinInstall LE or the InstallShield deployment tools. These tools will take a snapshot of your current system configuration and prompt you to install the software you want to package. Once the installation is complete, these tools will take another snapshot, record what changed on the filesystem and registry, and prompt you with a list of what it detected. You go through the list, make sure the changes listed were due to installing the software and not to errant behavior on the part of Windows, and then confirm the list. The software will create an MSI with the program's installer and a database of filesystem and registry changes.

Using this method, you gain the robustness and rollback features of using an MSI installer as opposed to ZAP files. However, the repackaging tools can tend to be a bit flaky, and sometimes you'll have difficulty installing them on multiple platforms. There's not a good way around that, other than obtaining an MSI directly from the software vendor, but it's somewhat of a middle ground between the inflexible ZAP files and a true MSI from the manufacturer.

6.5.2.2 An example deployment

In this section, I'll step through an actual software deployment using GP, publishing an application for a user:

1. Copy the MSI file and other necessary files to a network share. This might require an administrative installation, if your software has one available. Consult the documentation and deployment instructions for more on this.

   The network share should have these permissions:

   • Authenticated Users should have Read permissions.

   • Domain Computers should have Read permissions.

   • Administrators should have Read, Change, and Full Control permissions.

2. Create a new GPO and open it, or edit an existing GPO that you've created for the purposes of distributing this software, using the Group Policy Object Editor.

3. Navigate through the User Configuration and Software Settings nodes in the left pane.

4. Right-click Software Installation, and select Package from the New menu.

5. In the Find File window, use the Browse button to find the package you copied to the network share. You can select either an MSI file or a ZAP file in this step; if you select a ZAP file ensure that its related installer file is located in the same folder as the ZAP file.

   If you are using a ZAP file, make sure the SetupCommand directive in the files points to the network path that contains the setup file and not to the local path. Otherwise, Windows won't translate the path to the file correctly, and if the software isn't present at the same local path on target systems, the installation will fail.

6. On the Deploy Software screen, select whether to publish the software or assign the software. (Skip the Advanced Publish and Assign option at this point, which allows you to use transform files to modify the installation process for an application. This is covered a bit later in this chapter.) For this example, I'll publish the software.

7. Click OK, and the software is added to the policy object and is saved to the directory.

Of course, to assign an application to a user, you simply can follow the preceding steps and select Assign instead of Publish in step 6. To assign an application to a computer, use the same process, but use Computer Configuration instead of User Configuration in step 3 and select Assign instead of Publish in step 6.

6.5.2.3 Deployment properties

You'll probably want to fine-tune the settings for deployment, and you can do this through the properties box for the software. Right-click the name of the package inside the Group Policy Object Editor and then select Properties. The policy properties box contains the following six tabs.

General

On this tab, you can modify the name of the package that will be displayed in Add/Remove Programs. You also can view the version, publisher, language, and platform of the software. Figure 6-27 shows the General tab.

Figure 6-27. The General tab

Deployment

The Deployment tab lets you configure the deployment type and user interaction methods for the software. Under Deployment Type, you can select whether to publish or assign this software. Under Deployment Options, you can choose to "Auto-install this application by file extension activation," which prevents or allows application installation when a user attempts to open a file with an extension associated with the application. You also can elect to "Uninstall this application when it falls out of the scope of management," which dictates whether to remove the application when the user or computer leaves the scope of the current GPO. Additionally, you can choose "Do not display this package in the Add/Remove Programs control panel," which simply hides the application's availability. The application still will be installed when the user opens a file with the associated extension. The Install this application at logon option will allow applications assigned to computers to be installed once a user logs in to the computer and not during the computer's boot process, which is the default behavior. Finally, under the Installation user interface options, you can choose whether to eliminate most user intervention by installing the application using default values (with the Basic option) or to prompt the user for installation preferences and instructions (with the Maximum option). Figure 6-28 shows the Deployment tab.

Figure 6-28. The Deployment tab

Upgrades

On this tab you can specify that this new package will upgrade an existing installed package. You can make that mandatory by checking the Required upgrade for existing packages checkbox. To add a package to be upgraded, click the Add button and find the package to upgrade within the current object; alternatively, browse through your Active Directory structure by clicking A specific GPO and choosing a different GPO and software package. Then you can elect to uninstall the existing package and install the new package, or upgrade over the existing package. Figure 6-29 shows the Upgrades tab.

Figure 6-29. The Upgrades tab

Categories

In this tab you can create categories that will sort and filter the applications available through the Add/Remove Programs applet within the Control Panel. Users can more easily find the published application they want to install if they can click the type of software they need, rather than wading through a list of 100 possible applications. To add categories, simply click the Add button and enter a new category name. Once you've added the category, you can add packages under it. Choose a category from the Available categories pane and click Select to add the current package to it. Do this for each package you want to categorize. Figure 6-30 shows the Categories tab.

Figure 6-30. The Categories tab

Modifications

You can use a transform file (also called an MST file) to customize an MSI application's installation procedure; through the Modifications tab, you can use multiple MST files to ensure that various users, groups, and computers receive customized versions of a software package. To use a transform file for a particular GPO, click Add on this tab and browse on the filesystem for the MST file to apply. There are two caveats: you must have deployed an application using the "Advanced Publish or Assign" method, selected when creating the software installation GPO. Also, once an MST has been applied and the software has been deployed, modifications cannot be added or removed. Figure 6-31 shows the Modifications tab.

Figure 6-31. The Modifications tab

Security

The Security tab, very similar to other ACLs on other objects within Windows Server 2003, allows you to specify permissions on a GPO for users, computers, and groups. You can use this tab in conjunction with the security group filtering strategy, discussed earlier in this chapter, to limit the scope of an applied GPO. For example, one policy assigning Office to computers might apply only to sales, but a policy publishing Windows administrative tools might apply only to administrators. If you want to assign applications to computers, you need to add the Domain Computers group here, unless you already have a security group containing the computers you want. Figure 6-32 shows the Security tab.

Figure 6-32. The Security tab

Remember the following security settings guidelines when deploying software via security group filtering:

• If you want the policy to be applied to all members of a certain security group, add all the members to a group, add the group to the ACL for the object, and set the following permissions for the group: Apply Group Policy, allow; Read, allow. All members of the group will have the policy applied, except if they are a member of another group with either of the former permissions set to Deny.

• If you do not want the policy to be applied to all members of a certain security group, add all the members to a group, add the group to the ACL for the object, and set the following permissions for the group: Apply Group Policy, deny; Read, deny. All members of the group will not have the policy applied, regardless of their existing memberships to other groups.

• If group membership (at least in a specific group) shouldn't play a part in the application of this policy, leave permissions alone.

Look back earlier in the chapter to the section "The Scope of Group Policy Objects" for a refresher on this.

You also can determine the order in which applications will be installed for a given file extension, a useful feature if your organization associates one file extension with multiple software packages. To do so, right-click the Software Installation node within the Group Policy Object Editor (in the lefthand pane) and select Properties. From there, navigate to the File Extensions tab. Select an extension from the drop-down list box, and then adjust the priority, from highest to lowest, of each application in the list box using the Up and Down buttons. If only one application in GP is associated with an extension, this feature will be grayed out because no priority needs to be established.

You also can configure other deployment options on this property sheet, using the following tabs.

General

Here, you can configure the default action when adding new packages to this GPOwhether to assign them, publish them, or display a dialog asking which action to take. You also can set the default user interface options as well. Plus, you can indicate the path that will serve as the default location for new packages added to this GPO.

Advanced

On this tab, you can indicate that software packages should be uninstalled when they fall out of the scope of management. You also can allow 64-bit Windows client workstations to install 32-bit Windows applications, and extend this capability to applications deployed via a ZAP file.

Categories

The Categories tab was discussed a bit earlier in this section.

6.5.2.4 Redeploying and removing software

If you need to patch an existing software deployment that uses an MSI file, you can take advantage of the redeployment functionality of IntelliMirror. Simply copy the new MSI and associated files over the existing copies on the network share. Then, inside the GPO that contains the deployment configuration for the existing package, right-click the package in the details window inside the Group Policy Object Editor and select Redeploy from the All Tasks menu. Click the Yes button to confirm your choice. The first time the application is started on client computers, regardless of whether the package was assigned or published, the new MSI will be installed.

Along the same lines, if you need to remove installed software, you can right-click the package inside the Group Policy Object Editor and select Remove from the All Tasks menu. You'll be presented with the window shown in Figure 6-33.

You can choose to either forcibly remove the software immediately, which will uninstall the application no matter what, or simply remove the software from the list of available software, which will allow current installations to continue to use the software, but will prevent new computers from obtaining the software through GP.

6.5.2.5 Deploying service packs using GP

You also can distribute service packs for Windows 2000, XP, and Windows Server 2003 through the IntelliMirror software installation features of GPOs. Doing so can go a long way toward eliminating a tedious and time-consuming administrative task. You can assign the service pack to computers for mandatory deployment, or you can publish the service pack to a user so that he can choose to install it if his situation warrants it.

If you are assigning the service pack to computers, you simply can point a GPO to the UPDATE.MSI file included in the extracted portion of all current service packs from Microsoft. However, if you're publishing the service pack, you'll need to create a ZAP file and then point the software installation GPO to that ZAP file. Again, you can't publish MSI files.

To deploy a service pack using IntelliMirror, follow these steps:

1. Create a distribution share for the service pack and extract its contents there. This process is described in Chapter 2, or you can consult the readme files within the service pack distribution file for information.

2. If you are publishing the service pack to users, create a ZAP file pointing to UPDATE.EXE inside the folder containing the extracted service pack files.

3. Create a new GPO for the service pack. This isn't requiredyou can assign the service pack as part of default domain policy or any other level of policybut it's best to keep software installations to their own GPOs so that changes can be reversed easily.

4. In the GPO, navigate through Computer Configuration or User Configuration and then choose Software Installation.

5. Right-click Software Installation and choose Package from the New menu.

6. Find the network path to the service pack files and select either UPDATE.MSI if you're assigning to computers or the UPDATE.ZAP file you created earlier if you're publishing to users.

7. Choose Assigned or Published in the Deploy Software dialog box.

8. Click OK.

The policy is set and the service pack will either be assigned or published, depending on your choices. Keep in mind that service packs typically are large files, so you should deploy them after considering the effect that process would have on both your network bandwidth and the time it would take to install locally on the client machines. Additionally, I would avoid automatically deploying service packs on your domain controllers. These machines are sensitive beasts that hold the keys to your Active Directorymanually install service packs on these machines one by one and test them to make sure there are no ill effects.

6.5.3. IntelliMirror: Folder Redirection

You can use the folder redirection functionality of GP to change the target location of many folders within a particular user's Windows interface. For example, you can specify custom locations for the Application Data, Desktop, My Documents (including the My Pictures subfolder), and Start Menu folders. Using folder redirection circumvents the nasty problem of roaming profiles: severe network traffic hikes caused by copying large My Documents and Desktop folders to workstations around the network when users log on. You also can back up the share where the folders are redirected using a normal network backup procedure, automatically protecting the contents.

To access the folder redirection functionality, launch the Group Policy Object Editor for a particular GPO and navigate through User Configuration, Windows Settings, and Folder Redirection. In the righthand pane you'll see the four folders you can redirect. Right-click each folder to bring up the Properties window. Figure 6-34 shows this screen.

On the Target tab, you can choose the type of redirection for this policy. For this example, choose the basic method, which simply redirects all users' folders to the same location. Next, enter the target folder at the bottom of the screen under Root Path, and select the option to create a new folder for each user underneath the root path. Then, move to the Settings tab, and choose the following settings.

Grant the user exclusive rights to My Documents

If this setting is enabled, the user to whom the folder belongs and the local computer have administrative and exclusive rights to the folder, to the exclusion of all other objects. If this setting is disabled, the current permissions on the folder are kept.

Move the contents of My Documents to the new location

If this setting is enabled, everything in the current My Documents folder will be moved to the new, redirected location. If this option is disabled, nothing will be moved and the new My Documents folder will be empty.

Policy removal

You can adjust the Windows default setting, which leaves the folder in the redirected location if the redirection policy itself is removed. You also can choose to move the folder back to its initial location.

My Pictures preferences

The default action for the My Pictures subfolder is to follow the My Documents folder to wherever it rests.

6.5.3.1 Redirecting folders based on group membership

If you want to redirect some profile folders to different locations based on the different groups to which a user belongs, you can use the Advanced method of redirection inside the redirect policy properties page, on the Target tab. When you select Advanced from the drop-down setting box indicating the type of redirection, click the Add button. The Specify Group and Location box will appear, as shown in Figure 6-35.

Enter the name of a security group, and then enter the network path to the folders. Always use a UNC path, even if the folders are local, so that users taking advantage of roaming profiles will see the correct folders in an absolute path and not wrongly translate a local, relative path. Click OK when you're done, and then repeat the process for as many groups as you need.

If your users are creatures of habit, you even can turn on the Offline Files and Folders feature on the share where you've stored the redirected folders. This way, Windows will continue to display and use a customized environment even when the network is down and the share can't be reached.

6.5.3.2 Removing a redirection policy

It can be a bit difficult to track what happens to redirected folders if you decide to remove a redirection policy. It really depends on the appropriate setting on the Settings tab of the redirected folder's policy properties sheet.

If you've selected to redirect the folder back to the local user profile when the policy is removed, and the option to move the contents of the local folder to a new location is enabled, the folder will return to its original location and the contents of the folder will be copied back to the original location but not deleted from the redirected location. If the option to move the contents of the folder to a new location is disabled, the folder will revert to its original location, but the contents of the folder will not be copied or moved to the original location. This means the user is unable to access the contents of the redirected folder from the special folder's UI within the shell, but using a UNC path, she still can access the redirected folder and retrieve its contents manually. If you've selected to leave the folder in the new location when the policy is removed, the folder and its contents will remain at the redirected location, and the user will have access to it, regardless of whether the option to move the contents of the folder to the new location is enabled or disabled.

6.5.4. Software Restriction Policies

New to Windows Server 2003 are software restriction policies, which allow you to block the execution of certain programs. It's an excellent feature to use on terminal servers or machines serving as a public kiosk, so users are locked into one specific function and can't mess with administrative tools or Internet applications and utilities.

Windows can identify software to either restrict or allow in several different ways. For one, it can use hash rules, which are made by identifying characteristics of files and executables that come with a program and generating an algorithmic hash from them. Hashes are great for identifying specific versions of programs because the hash value would change when different files are used to compute the hash (which is a near certainty with newer version of a program). Certificate rules can indicate software via a digital signature, which is a useful method to secure authorized scripts. Windows also can identify software via its path and the Internet zone (inside Internet Explorer) from which a particular piece of software is downloaded. Finally, Windows can create a rule that catches any software not explicitly identified either in a list or by any other rule. (Control for programs executed within a browser is lacking from the GP standpoint, but improvements to Internet Explorer in Windows XP Service Pack 2 pick up a bit of this slack.) Windows matches programs to rules in the order in which they're listed in the software restriction GPO, and if more than one rule identifies the same program, the rule that catches the program most specifically will trump any other rule.

You might be tempted to create a rule that disallows programs from running by default aside from those explicitly placed in an exception list. This seems like an easy way out, but it really can lobotomize a system unless you take great care to create an exception for every Windows executable a user might need, including his application programs. It also can step on the toes of any user logon scripts that might be necessary to create a secure environment. If you decide to go this route, it's imperative that you extensively test any restriction policies and exception lists in a lab. Also, when you do create the actual software restriction GPO, make sure to add the Domain Administrators group to the GPO's ACL and explicitly deny the Apply Group Policy permission to the GPOthis will enable an administrator to reverse the policy and not lock himself out.

Once you're ready to create the policy, follow this procedure:

1. Create a new GPO for each restriction policy. This makes it easier to disable a policy that might be overly restrictive.

2. Choose Computer Configuration or User Configuration to apply the restrictions to machines or users, and then navigate through Windows Settings Security Settings Software Restriction Policies.

3. Right-click Software Restriction Policies and choose New Software Restriction Policy from the context menu.

4. Set a default identifier rule: in the left pane, click Security Levels, and then right-click a specific security level and choose Set as Default from the pop-up context menu.

5. Now, create the actual rules that will catch software on which to enforce a restriction. Right-click Additional Rules in the lefthand pane. Choose New Certificate Rule and select the certificate to require or block, New Hash Rule and the file to allow or block, New Internet Zone Rule and the zone from which to allow or block programs, or New Path Rule and the file or registry key to allow or restrict.

6. In the righthand pane, double-click Enforcement. Here, indicate how these restrictions should be enforced. Use of the following options is recommended:

   "All software files except libraries" will help you avoid blocking critical system and application function files.

   "All users except local administrators" indicates that Windows should enforce the policy for everyone except those in the local administrator group.

7. Next, in the righthand pane, double-click Designated File Types. On this sheet, review and add file extensions associated with applications included in the software restriction policies. The list should be fairly complete, but ensure that any scripting languages you use in your organization have their associated file extensions included.

8. Finally, in the righthand pane, double-click Trusted Publishers. Here you can specify whether normal users, local administrators, or enterprise administrators are allowed to decide what certificates to trust when opening digitally signed programs and controls.

6.5.5. Scripts

Using GP, you can assign scripts to entire domains, organizational units, sites, and groups instead of repeatedly entering the same login script into multiple users' profiles. You can launch four types of scripts using a GPO: logon and logoff scripts, which apply to users, and startup and shutdown scripts, which apply to computers. Startup scripts are executed before logon scripts, and logoff scripts are executed before shutdown scripts.

You can write scripts in any number of languages. Windows Server 2003 is prepared to accept Jscript (.JS) and Visual Basic Scripting Edition (.VBS) files in addition to batch (.BAT), compiled command scripts (.COM), and application executables (.EXE). Scripts to be run through GP are stored on domain controllers in %SystemRoot%\SYSVOL\yourdomain.com\Policies\scripts, with yourdomain.com replaced with your fully qualified domain name.

You can assign startup and shutdown scripts in GP using the following procedure:

1. In the Group Policy Object Editor, navigate in the lefthand pane through Computer Configuration, Windows Settings, and Scripts (Startup/Shutdown).

2. In the righthand pane, click Startup and Shutdown to modify the scripts assigned to each.

You can assign logon and logoff scripts in GP using the following procedure.

1. In the Group Policy Object Editor, navigate in the lefthand pane through User Configuration, Windows Settings, and Scripts (Logon/Logoff).

2. In the righthand pane, click Logon and Logoff to modify the scripts assigned to each.

You can further define properties for these scripts under the Computer Configuration/Administrative Templates and User Configuration/Administrative Templates/System/Scripts nodes in the Group Policy Object Editor. For users running scripts, you have the following options (see Figure 6-36):

• "Run logon scripts synchronously," which allows you to specify multiple scripts and have them run at the same time rather than in sequence as the default dictates.

• "Run legacy logon scripts hidden," which tells Windows not to display the DOS window when using a .COM or .BAT logon or logoff script

• "Run logon scripts visible," which indicates whether the actions and results of the logon script's execution should be displayed to the user

• "Run logoff scripts visible," which indicates whether the actions and results of the logoff script's execution should be displayed to the user

Figure 6-36 shows these options.

For computers running scripts, you can configure the following options:

• "Run logon scripts synchronously," which allows you to specify multiple scripts and have them run at the same time, rather than in sequence as the default dictates, on a per-computer rather than a per-user basis

• "Run startup scripts asynchronously," which allows to you to specify multiple scripts and have them run in sequence, rather than at the same time, as the default dictates

• "Run startup scripts visible," which indicates whether the actions and results of the startup script's execution should be displayed to the user

• "Run shutdown scripts visible," which indicates whether the actions and results of the shutdown script's execution should be displayed to the user

• "Maximum wait time for Group Policy scripts," which sets a cutoff time for the execution of scripts specified in GP before Windows simply cuts them off and continues with the process at hand

Figure 6-37 shows these options.