Performing routine tasks day after day, running around policing systems, and walking users through the basics aren’t efficient uses of your time. You’d be much more effective if you could automate these chores and focus on more important issues. Well, increasing productivity and allowing you to focus less on mundane matters and more on important ones is what automation is all about.
Microsoft Windows Server 2003 provides many resources that help you automate administrative tasks, policies, and procedures. This chapter concentrates on four areas:
Group policy management
User and computer script management
Security templates
Scheduling tasks
Group policies simplify administration by giving administrators central control over privileges, permissions, and capabilities of both users and computers. Through group policies you can:
Create centrally managed directories for special folders, such as My Documents. This is covered in the section of this chapter entitled "Centrally Managing Special Folders."
Control access to Windows components, system resources, network resources, Control Panel utilities, the desktop, and the Start menu. This is covered in the section of this chapter entitled "Using Administrative Templates to Set Policies."
Define user and computer scripts to run at specified times. This is covered in the section of this chapter entitled "User and Computer Script Management."
Configure policies for account lockout and passwords, auditing, user rights assignment, and security. This is covered in Chapter 6 to Chapter 10.
The sections that follow explain how you can work with group policies. The focus is on understanding and applying group policies.
You can think of a group policy as a set of rules that helps you manage users and computers. You can apply group policies to multiple domains, to individual domains, to subgroups within a domain, or to individual systems. Policies that apply to individual systems are referred to as local group policies and are stored on the local system only. Other group policies are linked as objects in the Active Directory directory service.
To understand group policies, you need to know a bit about the structure of Active Directory. In Active Directory, logical groupings of domains are called sites and subgroups within a domain are called organizational units (OUs). Thus, your network could have sites called NewYorkMain, CaliforniaMain, and WashingtonMain. Within the WashingtonMain site, you could have domains called SeattleEast, SeattleWest, SeattleNorth, and SeattleSouth. Within the SeattleEast domain, you could have organizational units called Information Services (IS), Engineering, and Sales.
Group policies apply only to systems running Windows 2000, Windows XP Professional, and Windows Server 2003. You set policies for Windows NT 4.0 systems with the System Policy Editor (Poledit.exe). For Windows 95 and Windows 98, you need to use the System Policy Editor provided with Windows 95 or Windows 98, respectively, and then copy the policy file to the Sysvol share on a domain controller.
Group Policy settings are stored in a Group Policy Object (GPO). One way to think of a GPO is as a container for the policies you apply and their settings. You can apply multiple GPOs to a single site, domain, or organizational unit. Because policy is described using objects, many object-oriented concepts apply. If you know a bit about object-oriented programming, you might expect the concepts of parent-child relationships and inheritance to apply to GPOs—and you’d be right.
Through inheritance, a policy applied to a parent container is inherited by a child container. Essentially, this means that a policy setting applied to a parent object is passed down to a child object. For example, if you apply a policy setting in a domain, the setting is inherited by organizational units within the domain. In this case, the GPO for the domain is the parent object and the GPOs for the organizational units are the child objects.
The order of inheritance is as follows:
Site --> Domain --> Organizational Unit
This means that the group policy settings for a site are passed down to the domains within that site and the settings for a domain are passed down to the organizational units within that domain.
As you might expect, you can override inheritance. To do this, you specifically assign a policy setting for a child container that contradicts the policy setting for the parent. As long as overriding of the policy is allowed (that is, overriding isn’t blocked), the child’s policy setting will be applied appropriately. To learn more about overriding and blocking GPOs, see the section entitled "Blocking, Overriding, and Disabling Policies," later in this chapter.
When multiple policies are in place, policies are applied in the following order:
Windows NT 4.0 policies (Ntconfig.pol)
Local group policies
Site group policies
Domain group policies
Organizational unit group policies
Child organizational unit group policies
If there are conflicts among the policy settings, the policy settings applied later have precedence and overwrite previously set policy settings. For example, organizational unit policies have precedence over domain group policies. As you might expect, there are exceptions to the precedence rule. These exceptions are discussed in the section entitled "Blocking, Overriding, and Disabling Policies," later in this chapter.
As you’ll discover when you start working with group policies, policy settings are divided into two broad categories:
Those that apply to computers
Those that apply to users
Although computer policies are normally applied during system startup, user policies are normally applied during logon. The exact sequence of events is often important in troubleshooting system behavior. The events that take place during startup and logon are as follows:
The network starts and then Windows Server 2003 applies computer policies. By default, the computer policies are applied one at a time in the previously specified order. No user interface is displayed while computer policies are being processed.
Windows Server 2003 runs startup scripts. By default, startup scripts are executed one at a time, with each completing or timing out before the next one starts. Script execution isn’t displayed to the user unless specified.
A user presses Ctrl+Alt+Del to log on. After the user is validated, Windows Server 2003 loads the user profile.
Windows Server 2003 applies user policies. By default, the policies are applied one at a time in the previously specified order. The user interface is displayed while user policies are being processed.
Windows Server 2003 runs logon scripts. Group policy logon scripts are executed simultaneously by default. Script execution isn’t displayed to the user unless specified. Scripts in the Netlogon share are run last in a normal command-shell window as in Windows NT 4.0.
Windows Server 2003 displays the start shell interface configured in Group Policy.
By default, Group Policy is refreshed only when a user logs off or a computer is restarted. You can change this behavior by setting a Group Policy refresh interval, as discussed in the section of this chapter entitled "Refreshing Group Policy." To do this, open a command prompt and type gpupdate.
Real World
Some user settings, such as Folder Redirection, can’t be updated when a user is logged on. The user must log off and then log back on for these settings to be applied. You can type gpupdate/logoff at the command line to log the user off automatically after the refresh. Similarly, some computer settings can be updated only at startup. The computer must be restarted for these settings to be applied. You can enter gpupdate/boot at the command line to restart the computer after the refresh.
Group policies were introduced with Windows 2000 and apply only to systems running Windows 2000, Windows XP Professional, and Windows Server 2003. As you might expect, each new version of the Windows operating system has brought with it changes to Group Policy. Sometimes these changes have made older policies obsolete on newer versions of Windows. In this case, the policy works only on a specific version of the Windows operating system, such as only on Windows 2000.
Generally speaking, however, most policies are forward-compatible. This means that policies introduced in Windows 2000 can, in most cases, be used on Windows 2000, Windows XP Professional, and Windows Server 2003. It also means that Windows XP Professional policies usually aren’t applicable to Windows 2000 and that policies introduced in Windows Server 2003 aren’t applicable to Windows 2000 or Windows XP Professional.
If a policy isn’t applicable to a particular version of the Windows operating system, you can’t enforce the policy on computers running those versions of the Windows operating system.
How will you know if a policy is supported on a particular version of Windows? Easy. The properties dialog box for each policy has a Supported On field in the Setting tab. This text-only field lists the policy’s compatibility with various versions of the Windows operating system. If you select the policy with the Extended display in the Group Policy Object Editor (GPOE), you’ll also see a Requirements entry that lists compatibility.
You can also install new policies when you add a service pack, install Windows applications, or add Windows components. This means that you’ll see a wide range of compatibility entries.
Each computer running Windows Server 2003 has one local group policy. The quickest way to access local policy on a local computer is to type the following command at a command prompt:
gpedit.msc /gpcomputer: "%computername%"This command starts the Group Policy Editor in a Microsoft Management Console (MMC) with its target set to the local computer. Here, %ComputerName% is an environment variable that sets the name of the local computer and must be enclosed in double quotation marks as shown. To access local policy on a remote computer, type the following command at a command prompt:
gpedit.msc /gpcomputer: "RemoteComputer"where RemoteComputer is the host name or fully qualified domain name (FQDN) of the remote computer. Again, the double quotation marks are required as shown in the following example:
gpedit.msc /gpcomputer: "corpsvr82"
You can also manage local policies on a computer by completing the following steps:
Open the Run dialog box by clicking Start and then choosing Run.
Type mmc in the Open field and then click OK. This opens the MMC.
In MMC, choose File, and then choose Add/Remove Snap-In. This opens the Add/Remove Snap-In dialog box.
In the Add Standalone Snap-In dialog box, select Group Policy Object Editor, and then click Add. This starts the Select Group Policy Object Wizard.
Under Group Policy Object, Local Computer should be selected by default. If you want to edit the local policy on your computer, simply click Finish. To find the local policy on another computer, click Browse. After you find the policy you want to work with, click OK and then click Finish.
Click Close and then click OK. You can now manage the local policy on the selected computer. For details, see the section entitled "Working with Group Policies," later in this chapter.
Local group policies are stored in the %SystemRoot%System32GroupPolicy folder on each Windows Server 2003 computer. In this folder you’ll find the following subfolders:
Adm. Stores administrative template files currently being used. These files end with the .adm file extension. The Adm folder is only on domain controllers.
Machine. Stores computer scripts in the Script folder and registry-based policy information for HKEY_LOCAL_MACHINE (HKLM) in the Registry.pol file.
User. Stores user scripts in the Script folder and registry-based policy information for HKEY_CURRENT_USER (HKCU) in the Registry.pol file.
Caution
You shouldn’t edit these folders and files directly. Instead, you should use the appropriate features of one of the Group Policy management tools. By default, these files and folders are hidden. If you want to view hidden files and folders in Windows Explorer, select Folder Options from the Tools menu, click the View tab, choose Show Hidden Files And Folders, clear Hide Protected Operating System Files, and then click OK.
Each site, domain, and organizational unit can have one or more group policies. Group policies listed higher in the group policy list have a higher precedence than policies listed lower in the list. As stated earlier, group policies set at this level are associated with Active Directory. This ensures that site policies are applied appropriately throughout the related domains and organizational units.
When you want to work with Active Directory–based group policy, you’ll find there are two available tools:
Group Policy Object Editor (GPOE). A standard editor for working with and managing Group Policy that’s included with a standard installation of Windows Server 2003.
Group Policy Management Console (GPMC). An extended management interface for Group Policy that’s available as a free download from the Microsoft Download Center (http://www.microsoft.com/downloads).
Note
In this book, I focus primarily on GPOE because it’s the standard management tool. If you want to use GPMC, you install it on the machines from which you will manage your organization’s policy settings and then use it as the primary management tool on those machines. Keep in mind that if you were to log on locally to a server or to another computer on which GPMC hasn’t been installed, you will see GPOE instead of GPMC.
Regardless of whether you are working with the GPOE or the GPMC, you’ll find that each domain in your organization has two default GPOs:
Default Domain Controllers Policy GPO. A default GPO created for and linked to the Domain Controllers organizational unit. This GPO is applicable to all domain controllers in a domain (as long as they aren’t moved from this organizational unit) and is used to manage security settings for domain controllers in a domain.
Default Domain Policy GPO. A default GPO created for and linked to the domain itself within Active Directory. This GPO is used to establish baselines for a wide variety of policy settings that apply to all users and computers in a domain.
The default GPOs are essential to the proper operation and processing of Group Policy. By default, the Default Domain Controllers Policy GPO has the highest precedence among GPOs linked to the Domain Controllers organizational unit, and the Default Domain Policy GPO has the highest precedence among GPOs linked to the domain.
Although the Default Domain Policy GPO includes a complete policy set, it isn’t meant for general management of Group Policy. As a best practice, you should edit the Default Domain Policy GPO (or the highest precedence GPO linked to the domain) only to manage the default Account Policies settings and, in particular, three specific areas of Account Policies: Password Policy, Account Lockout Policy, and Kerberos Policy. You should manage four other specific policies using the highest precedence GPO linked to the domain level as well. These policies (located in Group Policy under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options) are Accounts: Rename Administrator Account, Accounts: Rename Guest Account, Network Security: Force Logoff When Logon Hours Expire, and Network Access: Allow Anonymous SID/Name Translation.
To manage other areas of policy, you should create a new GPO and link it to the domain or an appropriate organizational unit within the domain. Why? You can configure some policy settings only at the domain level. Although configuring them in the Default Domain Policy GPO might seem to make the most sense, it’s better to create a separate GPO for these customized settings. Also, if group policy becomes corrupted and stops working, you can use the DCGPOFIX command-line tool to restore the Default Domain Policy GPO to its original state without having to worry about losing every customized setting you’ve applied to the GPO (only those that must be set at the domain level would be lost).
You create and edit site, domain, and organizational unit policies by completing the following steps:
For sites, you start the Group Policy snap-in from the Active Directory Sites And Services console. Open the Active Directory Sites And Services console.
For domains and organizational units, you start the Group Policy snap-in from the Active Directory Users And Computers console. Open the Active Directory Users And Computers console.
In the appropriate console root, right-click the site, domain, or organizational unit on which you want to create or manage a group policy. Then select Properties on the shortcut menu. This opens a Properties dialog box. Keep the following in mind:
If you right-click the domain node in Active Directory Users And Computers, you’ll have access to the Default Domain Policy GPO.
If you right-click the Domain Controllers organizational unit in Active Directory Users And Computers, you’ll have access to the Default Domain Controllers Policy GPO.
In the Properties dialog box, click the Group Policy tab. As Figure 4-1 shows, existing policies are listed in the Group Policy Object Links list.
To create a new policy, click New. You can now configure the policy as explained in the section entitled "Working with Group Policies," later in this chapter.
To edit an existing policy, select the policy and then click Edit. You can now edit the policy as explained in the section entitled "Working with Group Policies."
To change the priority of a policy, select the policy that you want to work with and then use the Up or Down button to change its position in the Group Policy Object Links list.
Site, domain, and organizational unit group policies are stored in the %SystemRoot%SysvolDomainPolicies folder on domain controllers. In this folder, you’ll find one subfolder for each policy you’ve defined on the domain controller. The policy folder names are the policy’s Global Unique Identifier (GUID). The GUIDs can be found on the policy’s Properties page in the General tab in the summary frame. Within these individual policy folders you’ll find the following subfolders:
Adm. Stores administrative template files currently being used. These files end with the .adm file extension. The Adm folder is only on domain controllers.
Machine. Stores computer scripts in the Script folder and registry-based policy information for HKEY_LOCAL_MACHINE (HKLM) in the Registry.pol file.
User. Stores user scripts in the Script folder and registry-based policy information for HKEY_CURRENT_USER (HKCU) in the Registry.pol file.
You can block policy inheritance at the site, domain, and OU level. This means that you could block policies that would otherwise be applied. At the site and domain level, you can also enforce policies that would otherwise be contradicted or blocked. This gives top-level administrators the ability to enforce policies and prevent them from being blocked. Another available option is to disable policies. You can disable a policy partially or entirely without deleting its definition.
You configure these policy options by completing the following steps:
Access the Group Policy tab for the site, domain, or OU you want to work with, as specified in Steps 1–4 of the section entitled "Creating and Editing Site, Domain, and Organizational Unit Policies," earlier in this chapter.
Select Block Policy Inheritance to prevent the inheritance of higher-level policies (unless those policies have the No Override option set).
Use the No Override option to prevent lower-level policies from blocking the policy settings. Select or clear the No Override option by double-clicking in the appropriate column to the right of the group policy entry. A check mark indicates that the option is selected.
Use the Disabled option to prevent the policy from being used. Select or clear the Disabled option by double-clicking in the appropriate column to the right of the group policy entry. A check mark indicates that the option is selected.
Another way to disable a policy is to disable an unused part of the GPO. When you do this, you block the Computer Configuration or User Configuration settings, or both, and don’t allow them to be applied. By disabling part of a policy that isn’t used, the application of GPOs and security will be faster.
You can enable or disable configuration settings in Group Policy by following these steps:
Access the Group Policy tab for the site, domain, or organizational unit you want to work with as specified in Steps 1–4 in the section entitled "Creating and Editing Site, Domain, and Organizational Unit Policies," earlier in this chapter.
Click Properties in the Global Policy tab, and then select or clear Disable Computer Configuration Settings and Disable User Configuration Settings.
Any group policy that you’ve created can be associated with another computer, organizational unit, domain, or site. By associating the policy with another object, you can use the policy settings without having to recreate them.
You apply an existing policy to a new location by completing the following steps:
Access the Group Policy tab for the site, domain, or organizational unit with which you want to work.
In the Group Policy tab, click Add. As shown in Figure 4-2, this opens the Add A Group Policy Object Link dialog box.
Use the tabs and fields provided to find the group policy you want to apply to the current location. When you find the policy, click OK.
Active Directory creates a link between the GPO and the site, domain, or organizational unit container you’re working with. Now, when you edit the policy in any location, you edit the master copy of the object and the changes are reflected globally.
You can disable or delete group policies that you don’t use. To disable a policy, double-click in the Disabled column to the right of the group policy entry. A check mark indicates that the option is selected. To delete a policy, follow these steps:
Access the Group Policy tab for the site, domain, or organizational unit you want to work with, as specified in Steps 1–4 in the section entitled "Creating and Editing Site, Domain, and Organizational Unit Policies," earlier in this chapter.
Select the policy you want to delete and then click Delete.
If the policy is linked, you have the option of deleting the link without affecting other containers that use the policy. To do this, in the Delete dialog box, select the Remove The Link From The List check box.
If the policy is linked, you can also delete the link and the related policy object, which permanently deletes the policy. To do this, select the Remove The Link And Delete The Group Policy Object Permanently check box.
When you make changes to a group policy, those changes are immediate. However, they aren’t propagated automatically. Client computers request policy when:
The computer starts
A user logs on
An application or user requests a refresh
A refresh interval is set for group policy and the interval has elapsed
As you learned previously in this chapter, you can request that a policy be refreshed on a local computer using the Gpupdate command-line utility. Simply type gpupdate at the command prompt. You can also refresh a policy by setting a specific refresh interval, which thereby periodically forces a refresh. Either way, however, the refresh is only a background refresh and some policies might not be updated. The only way to ensure that all user policies are updated is to have the user log off. The only way to ensure that all computer policies are updated is to restart the computer.
To set a refresh interval in a group policy, follow these steps:
Access the GPO for the site, domain, or organizational unit you want to work with, as specified in the section entitled "Creating and Editing Site, Domain, and Organizational Unit Policies," earlier in this chapter.
Access the Group Policy node by expanding Computer ConfigurationAdministrative TemplatesSystem and then selecting Group Policy.
In the details pane, double-click Group Policy Refresh Interval For Computers. This policy controls the background refresh rate for computer policies.
In the Setting tab, select Enabled. You can now set the refresh interval for computer policies using the options provided. With the default settings, group policy is updated every 90 minutes with a random offset of 0 to 30 minutes. The offset makes it less likely that multiple computers will request updates at the same time. Click OK.
Access User ConfigurationAdministrative TemplatesSystemGroup Policy.
In the details pane, double-click Group Policy Refresh Interval For Users. This policy controls the background refresh rate for computer policies.
In the Setting tab, select Enabled. You can now set the refresh interval for user policies using the options provided. Click OK when finished.
When applying a refresh, network traffic is generated. During the update, the local computer might be less responsive than normal, which might affect the user’s work.
Note
The refresh interval for computers doesn’t apply to domain controllers. If you want domain controllers to regularly refresh a policy, access Computer ConfigurationAdministrative TemplatesSystemGroup Policy and then double-click Group Policy Refresh Interval For Domain Controllers. You can now set the refresh interval.
Real World
You want to ensure that updates don’t occur too frequently yet are timely enough to meet expectations or requirements. The more often a policy is refreshed, the more traffic that’s generated over the network. In a large installation, you typically want to set a longer refresh rate than the default to reduce network traffic, particularly if the policy affects hundreds of users or computers. In any installation where users complain about their computers periodically getting sluggish, you might want to increase the policy refresh interval as well. Consider that a once a day or once a week update might be all that it takes to keep policies current enough to meet your organization’s needs.
After you’ve selected a policy for editing or created a new policy, you use the GPOE to work with group policies. Techniques for working with this console are examined in this section.
As Figure 4-3 shows, the GPOE has two main nodes:
Computer Configuration. Allows you to set policies that should be applied to computers, regardless of who logs on
User Configuration. Allows you to set policies that should be applied to users, regardless of which computer to which they log on
Figure 4-3. The configuration of the Group Policy Object Editor depends on the type of policy you’re creating and the add-ons installed.
The exact configuration of Computer Configuration and User Configuration depends on the add-ons installed and which type of policy you’re creating. Still, you’ll usually find that both Computer Configuration and User Configuration have subnodes for:
Software Settings. Sets policies for software settings and software installation. When you install software, subnodes might be added to Software Settings.
Windows Settings. Sets policies for folder redirection, scripts, and security.
Administrative Templates. Sets policies for the operating system, Windows components, and programs. Administrative templates are configured through template files. You can add or remove template files whenever you need to.
Note
A complete discussion of all the available options is beyond the scope of this book. The sections that follow focus on using folder redirection and administrative templates. Scripts are discussed in the section of this chapter entitled "User and Computer Script Management." Security is covered in Chapter 6 to Chapter 10.
You can centrally manage special folders used by Windows Server 2003 through folder redirection. You do this by redirecting special folders to a central network location instead of using multiple default locations on each computer. The special folders you can centrally manage are:
Application Data
Desktop
Start Menu
My Documents
My Pictures
You have two options for redirection. You can redirect a special folder to the same network location for all users or you can designate locations based on user membership in security groups. In either case, you should make sure that the network location you plan to use is available as a network share. See Chapter 14, for details on sharing data on the network.
You redirect a special folder to a single location by completing the following steps:
Access the GPO for the site, domain, or organizational unit you want to work with as specified in the section entitled "Creating and Editing Site, Domain, and Organizational Unit Policies," earlier in this chapter.
In the User Configuration node, you’ll find Windows Settings. Expand this entry by double-clicking it, and then select Folder Redirection.
Right-click the special folder with which you want to work, such as Application Data, and then select Properties on the shortcut menu. This opens a properties dialog box similar to the one shown in Figure 4-4.
Because you’re redirecting the folder to a single location, use the Setting selection list in the Target tab to choose Basic—Redirect Everyone’s Folder To The Same Location.
Under Target Folder Location, you have several options. The exact options available depend on the folder you’re working with and include the following:
Redirect To The User’s Home Directory. If you use this option, the folder is redirected to a subdirectory within the user’s home directory. You set the location of the user’s home directory with the %HomeDrive% and %HomePath% environment variables.
Create A Folder For Each User Under The Root Path. If you use this option, a folder is created for each user at the location you enter in the Root Path field. The folder name is the user account name as specified by %UserName%. Thus, if you entered the root path value \ZetaUserDocuments, the folder for WilliamS would be located at \ZetaUserDocumentsWilliamS.
Redirect To The Following Location. If you use this option, the folder is redirected to the exact location you enter in the Root Path field. Here, you typically want to use an environment variable to customize the folder location for each user. For example, you could use the root path value \ZetaUserData\%UserName%docs.
Redirect To The Local Userprofile Location. If you use this option, the folder is redirected to a subdirectory within the user profile directory. You set the location of the user profile with the %UserProfile% variable.
Click the Settings tab, and then configure additional options using the following fields:
Grant The User Exclusive Rights To ... Gives users full rights to access their data in the special folder
Move The Contents Of ... To The New Location. Moves the data in the special folders from the individual systems on the network to the central folder(s)
Click OK to complete the process.
You redirect a special folder based on group membership by completing the following steps:
Access the GPO for the site, domain, or organizational unit with which you want to work.
In the User Configuration node, you’ll find Windows Settings. Expand this entry by double-clicking it, and then select Folder Redirection.
Right-click the special folder you want to work with, such as Application Data, and then select Properties on the shortcut menu.
In the Target tab, use the Setting selection list to choose Advanced–Specify Locations For Various User Groups. As shown in Figure 4-5, a Security Group Membership panel is added to the properties dialog box.
Click Add to display the Specify Group And Location dialog box. Or select an existing group entry and click Edit to modify its settings.
In the Security Group Membership field, type the name of the security group for which you want to configure redirection. Or click Browse to find a security group to add.
As with basic redirection, the options available depend on the folder you’re working with and include the following:
Redirect To The User’s Home Directory. If you use this option, the folder is redirected to a subdirectory within the user’s home directory. You set the location of the user’s home directory with the %HomeDrive% and %HomePath% environment variables.
Create A Folder For Each User Under The Root Path. If you use this option, a folder is created for each user at the location you enter in the Root Path field. The folder name is the user account name as specified by %UserName%. Thus, if you entered the root path value \ZetaUserDocuments, the folder for WilliamS would be located at \ZetaUserDocumentsWilliamS.
Redirect To The Following Location. If you use this option, the folder is redirected to the exact location you enter in the Root Path field. Here, you typically want to use an environment variable to customize the folder location for each user. For example, you could use the root path value \ZetaUserData\%UserName%docs.
Redirect To The Local Userprofile Location. If you use this option, the folder is redirected to a subdirectory within the user profile directory. You set the location of the user profile with the %UserProfile% variable.
Click OK. Then repeat Steps 5–7 for other groups that you want to configure.
When you’re done creating group entries, click the Settings tab and then configure additional options using the following fields:
Grant The User Exclusive Rights To ... Gives users full rights to access their data in the special folder
Move The Contents Of ... To The New Location. Moves the data in the special folders from the individual systems on the network to the central folder(s)
Click OK to complete the process.
Sometimes you might want to remove redirection from a particular special folder. You remove redirection by completing the following steps:
Access the Folder Redirection subnode in the GPOE.
Right-click the special folder you want to work with, and then select Properties on the shortcut menu.
Click the Settings tab, and then make sure that an appropriate Policy Removal option is selected. Two options are available:
Leave The Folder In The New Location When Policy Is Removed. When you select this option, the folder and its contents remain at the redirected location and current users are still permitted to access the folder and its contents at this location.
Redirect The Folder Back To The Local Userprofile Location When Policy Is Removed. When you select this option, the folder and its contents are copied back to the original location. The contents aren’t deleted from the previous location, however.
If you changed the Policy Removal option, click Apply. Then click the Target tab. Otherwise, just click the Target tab.
To remove all redirection definitions for the special folder, use the Setting selection list to choose Not Configured.
To remove redirection for a particular security group, select the security group in the Security Group Membership panel and then click Remove. Click OK.
Administrative templates provide easy access to registry-based policy settings that you might want to configure.
As Figure 4-6 shows, a default set of administrative templates is configured for users and computers in the GPOE. You can add or remove administrative templates as well. Any changes you make to policies available through the administrative templates are saved in the registry. Computer configurations are saved in HKEY_LOCAL_MACHINE (HKLM), and user configurations are saved in HKEY_CURRENT_USER (HKCU).
You can view the currently configured templates in the Administrative Templates node of the GPOE. This node contains policies that can be configured for local systems, organizational units, domains, and sites. Different sets of templates are found under Computer Configuration and User Configuration. You can manually add templates containing new policies in the GPOE when you install new Windows components.
You set the user interface for the Administrative Templates node in .adm files. These files are formatted as ASCII text, and you can edit them using a standard text editor. When you set policies through the Administrative Templates node, the policy settings are saved in Registry.pol files. Separate Registry.pol files are used for HKEY_LOCAL_MACHINE (HKLM) and HKEY_CURRENT_USER (HKCU).
The best way to get to know what administrative template policies are available is to browse the Administrative Templates nodes in the GPOE. As you browse the templates, you’ll find that policies are in one of three states:
You can enable, disable, and configure policies by completing the following steps:
Access the GPO for the site, domain, or organizational unit with which you want to work.
Access the Administrative Templates folder in the Computer Configuration or User Configuration node, whichever is appropriate for the type of policy you want to set.
In the left pane, select the subfolder containing the policies with which you want to work. The related policies are then displayed in the right pane.
Double-click or right-click a policy and choose Properties to display its related Properties dialog box.
Click the Explain tab to see a description of the policy. The description is available only if one is defined in the related .adm file.
To set the policy’s state, click the Setting tab and then use the following option buttons to change the policy’s state:
Not Configured. The policy isn’t configured.
Enabled. The policy is enabled.
Disabled. The policy is disabled.
If you enabled the policy, set any additional parameters specified in the Setting tab, and then click Apply.
Use the Previous Policy and Next Policy buttons to manage other policies in the current folder. Then configure them in the same way.
Click OK when you’re finished managing policies.
You can add or remove template folders in the GPOE. To do this, complete the following steps:
Access the GPO for the site, domain, or organizational unit with which you want to work.
Right-click the Administrative Templates folder in the Computer Configuration or User Configuration node, whichever is appropriate for the type of template you want to add or remove. This displays the Add/Remove Templates dialog box shown in Figure 4-7.
To add new templates, click Add. Then, in the Policy Templates dialog box, click the template you want to add and click Open.
To remove an existing template, select the template to remove, and then click Remove.
When you’re finished adding and removing templates, click Close.
With Windows Server 2003, you can configure four types of scripts:
Computer Startup. Executed during startup
Computer Shutdown. Executed prior to shutdown
User Logon. Executed when a user logs on
User Logoff. Executed when a user logs off
You can write scripts as command-shell batch scripts ending with the .bat or .cmd extension or as scripts that use the Windows Script Host (WSH). WSH is a feature of Windows Server 2003 that lets you use scripts written in a scripting language, such as VBScript, without the need to insert the script into a Web page. To provide a multipurpose scripting environment, WSH relies on scripting engines. A scripting engine is the component that defines the core syntax and structure of a particular scripting language. Windows Server 2003 ships with scripting engines for VBScript and JScript. Other scripting engines are also available.
Computer startup and shutdown scripts are assigned as part of a group policy. In this way, all computers that are members of the site, domain, or organizational unit, or all three, execute scripts automatically when they’re booted or shut down.
Note
You can also assign computer startup scripts as scheduled tasks. You schedule tasks using the Scheduled Task Wizard. See the section entitled "Scheduling Tasks," later in this chapter, for details.
To assign a computer startup or shutdown script, follow these steps:
For easy management, copy the scripts you want to use to the MachineScriptsStartup or MachineScriptsShutdown folder for the related policy. Policies are stored in the %SystemRoot%SysvolDomainPolicies folder on domain controllers.
Access the GPO for the site, domain, or organizational unit with which you want to work.
In the Computer Configuration node, double-click the Windows Settings folder. Then click Scripts.
To work with startup scripts, right-click Startup and then select Properties. Or right-click Shutdown and then select Properties to work with shutdown scripts. This opens a dialog box similar to the one shown in Figure 4-8.
Click Show Files. If you copied the computer script to the correct location in the policies folder, you should see the script.
Click Add to assign a script. This opens the Add A Script dialog box. In the Script Name field, type the name of the script you copied to the MachineScriptsStartup or the MachineScriptsShutdown folder for the related policy. In the Script Parameters field, enter any command-line arguments to pass to the command-line script or parameters to pass to the scripting host for a WSH script. Repeat this step to add other scripts.
During startup or shutdown, scripts are executed in the order in which they’re listed in the properties dialog box. Use the Up or Down button to reposition scripts as necessary.
If you want to edit the script name or parameters later, select the script in the Script For list and then click Edit.
To delete a script, select the script in the Script For list, and then click Remove.
You can assign user scripts in one of three ways:
You can assign logon and logoff scripts as part of a group policy. In this way, all users who are members of the site, domain, or organizational unit, or all three, execute scripts automatically when they log on or log off.
You can also assign logon scripts individually through the Active Directory Users And Computers console. In this way, you can assign each user or group a separate logon script. For details, see the section entitled "Configuring the User’s Environment Settings" in Chapter 10.
You can also assign individual logon scripts as scheduled tasks. You schedule tasks using the Scheduled Task Wizard. See the section entitled "Scheduling Tasks," later in this chapter, for details.
To assign a group policy user script, complete the following steps:
For easy management, copy the scripts you want to use to the UserScriptsLogon or the UserScriptsLogoff folder for the related policy. Policies are stored in the %SystemRoot%SysvolDomainPolicies folder on domain controllers.
Access the GPO for the site, domain, or organizational unit with which you want to work.
Double-click the Windows Settings folder in the User Configuration node. Then click Scripts.
To work with logon scripts, right-click Logon and then select Properties. Or right-click Logoff and then select Properties to work with logoff scripts. This opens a dialog box similar to the one shown in Figure 4-9.
Click Show Files. If you copied the user script to the correct location in the policies folder, you should see the script.
Click Add to assign a script. This opens the Add A Script dialog box. In the Script Name field, type the name of the script you copied to the UserScriptsLogon or the UserScriptsLogoff folder for the related policy. In the Script Parameter field, enter any command-line arguments to pass to the command-line script or parameters to pass to the scripting host for a WSH script. Repeat this step to add other scripts.
During logon or logoff, scripts are executed in the order in which they’re listed in the Properties dialog box. Use the Up or Down button to reposition scripts as necessary.
If you want to edit the script name or parameters later, select the script in the Script For list and then click Edit.
To delete a script, select the script in the Script For list, and then click Remove.
Sound security practices and settings are essential to successful systems administration. One way to set security policy is to use security templates.
Security templates provide a centralized way of managing security-related settings for workstations and servers. You use security templates to apply customized sets of group policy definitions that are security-related. These policy definitions generally affect:
Account policies. Settings control security for passwords, account lockout, and Kerberos.
Local policies. Settings control security for auditing, user rights assignment, and other security options.
Event log policies. Settings control security for event logging.
Restricted groups policies. Settings control security for local group membership administration.
System services policies. Settings control security and startup mode for local services.
File system policies. Settings control security for the local file system.
Registry policies. Settings control the values of security-related registry keys.
Security templates are available in all Windows Server 2003 installations and can be imported into any group policy. Templates are stored in the %SystemRoot%SecurityTemplates directory and you can access them using the Security Templates snap-in, shown in Figure 4-10.
You can also use the snap-in to create new templates. The standard templates distributed with Windows Server 2003 include:
DC security. Contains the default security settings for domain controllers
setup security. Contains the default security settings for member servers
securedc. Contains moderate security settings for domain controllers
securews. Contains moderate security settings for workstations
hisecdc. Contains very stringent security settings for domain controllers
hisecws. Contains very stringent security settings for workstations
Tip
After you select the template that you want to use, you should go through each setting that the template will apply and evaluate how the setting will affect your environment. If a setting doesn’t make sense, you should modify or delete it as appropriate.
You don’t use the Security Templates snap-in to apply templates. You apply templates using the Security Configuration And Analysis snap-in. You can also use Security Configuration And Analysis to compare the settings in a template to the existing settings on a computer. The results of the analysis will highlight areas where the current settings don’t match those in the template. This is useful to determine if security settings have changed over time.
You can access the security snap-ins by completing the following steps:
Open the Run dialog box by clicking Start and then selecting Run.
Type mmc in the Open field and then click OK. This opens the MMC.
In MMC, click File, and then click Add/Remove Snap-In. This opens the Add/Remove Snap-In dialog box.
In the Standalone tab, click Add.
In the Add Standalone Snap-In dialog box, click Security Templates, and then click Add.
Click Security Configuration And Analysis, and then click Add.
Close the Add Standalone Snap-In dialog box by clicking Close, and then click OK.
As stated previously, you use the Security Templates snap-in to view existing templates or to create new templates. Once you’ve created a template or determined that you want to use an existing template, you can then configure and analyze the template by completing the following steps:
Access the Security Configuration And Analysis snap-in.
Right-click the Security Configuration And Analysis node and then select Open Database. This displays the Open Database dialog box.
Type a new database name in the File Name field and then click Open.
The Import Template dialog box is displayed. Select the security template that you want to use, and then click Open.
Right-click the Security Configuration And Analysis node, and then choose Analyze Computer Now. When prompted to set the error log path, type a new path or click OK to use the default path.
Wait for the snap-in to complete the analysis of the template. Afterward, review the findings and update the template as necessary. You can view the error log by right-clicking the Security Configuration And Analysis node and choosing View Log file.
When you’re ready to apply the template, right-click the Security Configuration And Analysis node and choose Configure Computer Now. When prompted to set the error log path, click OK. The default path should be fine.
View the configuration error log by right-clicking the Security Configuration And Analysis node and choosing View Log File. Note any problems and take action as necessary.
When you manage systems, you’ll often want to perform tasks such as updates or maintenance during nonbusiness hours. This way, you don’t affect productivity and workflow. But who wants to come in at 3:00 on a Monday morning? Fortunately, using the Task Scheduler service, you can schedule one-time or recurring tasks to run automatically at any hour of the day or night.
You automate tasks by running command-shell scripts, WSH scripts, or applications that execute the necessary commands for you. For example, if you wanted to back up the system drive every weekday at midnight, you could create a script that runs backups for you and records progress and success/failure results in a log file.
In Windows Server 2003, you can schedule tasks on local and remote systems using the Scheduled Task Wizard, the command-line AT utility, or the command-line SCHTASK utility. Each utility has its advantages and disadvantages.
Scheduled Task Wizard provides a point-and-click interface to task assignment. This makes it easy to configure tasks quickly without having to worry about syntax issues. The disadvantage is that you don’t have a central location that you can use to check for scheduled tasks throughout the enterprise and you have to access the wizard separately on each individual system that you want to configure.
The command-line AT scheduler, on the other hand, doesn’t have a friendly point-and-click interface. This means you’ll have to learn the necessary command syntax and type in commands. The advantage to AT is that you can designate a single server as a task scheduler and you can view and set tasks throughout the enterprise on this single server.
SCHTASKS is a command-line utility that is just as versatile as the Scheduled Task Wizard. You can use the utility to configure tasks to run on a specific schedule, set run permissions, and configure startup, log on, and idle processor commands. Like AT, SCHTASKS allows you to schedule tasks to run anywhere on the network. More important, you can use SCHTASKS to view status information for any scheduled tasks that are configured on a system, including those created using AT, SCHTASKS itself, and the Scheduled Task Wizard.
The following sections discuss how to use the Scheduled Task Wizard. A complete discussion of AT and SCHTASKS is beyond the scope of this book. However, if you want to use SCHTASKS to examine scheduled tasks configured on any system on the network, simply type the following command at a command prompt:
schtasks /query /s SystemName
where SystemName is the name of the system that you want to examine, such as
schtasks /query /s corpserver01
The Windows Server 2003 service that controls task scheduling is the Task Scheduler service. Task Scheduler logs on as the LocalSystem account by default. This account usually doesn’t have adequate permissions to perform administrative tasks. Because of this, when you use the AT scheduler, you should configure Task Scheduler to use a specific user account that has adequate user privileges and access rights to run the tasks you want to schedule.
You should also make sure that the Task Scheduler service is configured to start automatically on all the systems on which you want to schedule tasks. Set the Task Scheduler startup and logon account as specified in the sections entitled "Configuring Service Startup" and "Configuring Service Logon" in Chapter 3.
A script should configure whatever user settings are necessary. This ensures that everything the script does is under its control and that domain user settings, such as drive mappings, are available as needed.
You can use the Scheduled Task Wizard to schedule tasks on the local or remote system to which you’re currently connected. You access the Scheduled Task Wizard and currently scheduled tasks through the Scheduled Tasks folder.
You can access the Scheduled Tasks folder on a local system with either of the following techniques:
Start Control Panel and then click Scheduled Tasks.
Start Windows Explorer, click My Computer, then Control Panel, and then Scheduled Tasks.
You can access the Scheduled Tasks folder on a remote system by completing the following steps:
Start Windows Explorer, and then use the My Network Places node to navigate to the computer with which you want to work.
Select the computer’s icon and then double-click Scheduled Tasks.
To create scheduled tasks on remote computers, right-click in the details pane to display a shortcut menu. Point to New and then select Scheduled Task. You then configure the scheduled task using a properties dialog box rather than the Scheduled Task Wizard.
Entries in the Scheduled Tasks folder show currently scheduled tasks. You can work with entries in the Scheduled Tasks folder using any of the following techniques:
Double-click Add Scheduled Task to start the Scheduled Task Wizard. This option is not available on a remote system. However, you could create the task locally using the wizard and then copy the scheduled task to the Scheduled Tasks folder on the remote system.
Double-click an existing task entry to view or change its properties. You can set advanced options through the Settings tab.
Select a task entry and click the Delete button on the toolbar to delete the task.
To schedule a task with the Scheduled Task Wizard, follow these steps:
Start the Scheduled Task Wizard by double-clicking Add Scheduled Task in the Scheduled Tasks folder. Read the Welcome dialog box and then click Next.
Using the page shown in Figure 4-11, select a program to schedule. The page shows key applications registered on the system, such as Disk Cleanup and Synchronize. The page doesn’t show available scripts, however. If the program or script you want to use isn’t listed, click Browse to open the Select Program To Schedule dialog box. In the dialog box, select the program or script you want to run and then click Next.
Type a name for the task. The name should be short but descriptive so you can quickly determine what the task does.
Select a run schedule for the task. Tasks can be scheduled to run periodically (daily, weekly, or monthly), or when a specific event occurs, such as when the computer starts or when the task’s user logs on.
Click Next and then select a date and time to run the scheduled task. The next dialog box you see depends on when the task is scheduled to run.
After you’ve configured a start date and time, click Next to continue. Then type a user name and password that can be used when running the scheduled task. This user name must have appropriate permissions and privileges to run the scheduled task.
The final wizard page provides a summary of the task you’re scheduling. Click Finish to complete the scheduling process. If an error occurs when you create the task, you’ll see an error prompt. Click OK. The task should still be created. Afterward, in the Scheduled Tasks folder, double-click the task to correct the problem in the related Properties dialog box.
