Chapter 4 - Automating Administrative Tasks, Policies, and Procedures

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 2000 provides many resources that help you automate administrative tasks, policies, and procedures. This chapter concentrates on three areas:

• Group policy management

• User and computer script management

• Scheduling Tasks

On This Page

Group Policy Management Working with Group Policies Scheduling Tasks

Group Policy Management

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 Desktop. This is covered in this chapter in the section 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 this chapter in the section entitled "Using Administrative Templates to Set Policies."

• Define user and computer scripts to run at specified times. This is covered in this chapter in the section entitled "User and Computer Script Management."

• Configure policies for account lockout and passwords, auditing, user rights assignment, and security. This is covered in Part II of this book, "Microsoft Windows 2000 Directory Services Administration."

The sections that follow explain how you can work with group policies. The focus is on understanding and applying group policies.

Understanding Group Policies

You can think of a group policy as a set of rules that helps you manage users and computers. Group policies can be applied 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 service.

To understand group policies, you need to know a bit about the structure of Active Directory directory service. In Active Directory, logical groupings of domains are called sites and subgroups within a domain are called organizational units. 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 only apply to systems running Windows 2000. You set policies for Microsoft Windows NT 4.0 systems with the System Policy Editor (poledit.exe). For Microsoft Windows 95 and Microsoft 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.

In What Order Are Multiple Policies Applied?

When multiple policies are in place, policies are applied in the following order:

1. Windows NT 4.0 policies (NTConfig.pol)

2. Local group policies

3. Site group policies

4. Domain group policies

5. Organizational unit group policies

6. 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 later in the section of this chapter entitled "Blocking, Overriding, and Disabling Policies."

When Are Group Policies Applied?

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

While 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:

1. The network starts and then Windows 2000 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.

2. Windows 2000 runs startup scripts. By default, startup scripts are executed one at a time, with each completing or timing out before the next starts. Script execution isn't displayed to the user unless specified.

3. A user presses Ctrl+Alt+Del to log on. After the user is validated, Windows 2000 loads the user profile.

4. Windows 2000 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.

5. Windows 2000 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.

6. Windows 2000 displays the start shell interface configured in Group Policy.

Managing Local Group Policies

Each computer running Windows 2000 has one local group policy. You manage local policies on a computer by completing the following steps:

1. Open the Run dialog box by clicking Start and then clicking Run.

2. Type mmc in the Open field and then click OK. This opens the Microsoft Management Console (MMC).

3. In MMC, click Console, then click Add/Remove Snap-In. This opens the Add/Remove Snap-In dialog box.

4. On the Standalone tab, click Add.

5. In the Add Snap-In dialog box, click Group Policy, and then click Add. This opens the Select Group Policy Object dialog box.

6. Click Local Computer to edit the local policy on your computer or browse to find the local policy on another computer.

7. Click Finish, and then click Close.

8. Click OK. You can now manage the local policy on the selected computer. For details, see the section of this chapter entitled "Working with Group Policies."

Local group policies are stored in the %SystemRoot%\system32\GroupPolicy folder on each Windows 2000 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 the Group Policy console.

Managing Site, Domain, and Unit Policies

Each site, domain, and organization 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 get applied appropriately throughout the related domains and organizational units.

Creating and Editing Site, Domain, and Unit Policies

You create and edit site, domain, and unit policies by completing the following steps:

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

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

3. In the console root, right-click the site, domain, or 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.

4. In the properties dialog box, select the Group Policy tab. As Figure 4-1 shows, existing policies are listed in the Group Policy Object Links list.

   

   Figure 4-1: Use the Group Policy tab to create and edit policies.

5. To create a new policy or edit an existing policy, click New. You can now configure the policy as explained in the section of this chapter entitled "Working with Group Policies."

6. To edit an existing policy, select the policy and then click Edit. You can now edit the policy as explained in the section of this chapter entitled "Working with Group Policies."

7. To change the priority of a policy, use the Up or Down buttons to change its position in the Group Policy Object Links list.

Site, domain, and unit group policies are stored in the %SystemRoot%\SYSVOL\ domain\policies folder on domain controllers. In this folder you'll find one subfolder for each policy you've defined on the domain controller. Within these individual policy folders, you'll find

• 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 the Group Policy console.

Blocking, Overriding, and Disabling Policies

You can block policy inheritance at the site, domain, and organizational unit 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:

1. Access the Group Policy tab for the site, domain, or organizational unit you want to work with as specified in steps 1–4 of the "Creating and Editing Site, Domain, and Unit Policies" section of this chapter.

2. Select Block Policy Inheritance to prevent the inheritance of higher-level policies (unless those policies have the No Override option set).

3. Use the No Override option to prevent lower-level policies from blocking the policy settings. Set 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 the option is selected.

4. Use the Disabled option to prevent the policy from being used. Set or clear the Disabled option by double-clicking in the appropriate column to the right of the group policy entry. A check mark indicates the option is selected.

Tip Another way to disable a policy is to block Computer Configuration or User Configuration settings, or both. To do this, click Properties in the Global Policy tab, then set or clear Disable Computer Configuration Settings and Disable User Configuration Settings.

Applying an Existing Policy to a New Location

Any group policy that you've created can be associated with another computer, 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:

1. Access the Group Policy tab for the site, domain, or organizational unit you want to work.

2. In the Group Policy tab, click Add. As shown in Figure 4-2, this opens the Add A Group Policy Object Link dialog box.

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

   

   Figure 4-2: Use the Add A Group Policy Object Link dialog box to link existing policies to new locations without having to recreate the policy definition.

4. Active Directory creates a link between the group policy object and the site, domain, or 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.

Deleting a Group Policy

You can disable or delete group policies that you don't use. To disable a policy, see the section of this chapter entitled "Blocking, Overriding, and Disabling Policies." To delete a policy, follow these steps:

1. Access the Group Policy tab for the site, domain, or organizational unit you want to work with as specified in steps 1–4 of the section of this chapter entitled "Creating and Editing Site, Domain, and Unit Policies."

2. Select the policy you want to delete and then click Delete.

3. 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 Remove The Link From The List.

4. 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 Remove The Link And Delete The Group Policy Object Permanently.

Working with Group Policies

Once you've selected a policy for editing or created a new policy, you use the Group Policy console to work with group policies. Techniques for working with this console are examined in this section.

Getting to Know the Group Policy Console

As Figure 4-3 shows, the Group Policy console 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 they log on to.

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

  

  Figure 4-3: The configuration of the Group Policy console depends on the type of policy you're creating and the add-ons installed.

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 entitled "User and Computer Script Management." Security is covered in Part II of this book, "Microsoft Windows 2000 Directory Services Administration."

Centrally Managing Special Folders

You can centrally manage special folders used by Windows 2000 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 13 for details on sharing data on the network.

Redirecting a Special Folder to a Single Location

You redirect a special folder to a single location by completing the following steps:

1. Access the Group Policy console for the site, domain, or organizational unit you want to work with as specified in the section of this chapter entitled "Creating and Editing Site, Domain, and Unit Policies."

2. In the User Configuration node, you'll find Windows Settings. Expand this entry by double-clicking it, and then select Folder Redirection.

3. Right-click the special folder you want to work with, 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.

4. In the Target tab, use the Setting selection list to choose Basic - Redirect Everyone's Folder To The Same Location.

5. Enter the folder path to use in the Target Folder Location field. The folder you select is where all data for the special folder is stored. The folder path should be set to a shared folder that is available on the network through a Universal Naming Convention (UNC) path, such as \\Zeta\UserData. Click Browse to search for the folder in the Browse For Folder dialog box.

   

   Figure 4-4: Set options for the redirection using the Application Data Properties dialog box.

   Tip Normally, user data isn't stored separately. To specify that user data should be placed in subfolders that are specific to the user, add %UserName% to the path. For example, instead of setting the folder path to \\Zeta\UserData, you would use \\Zeta\UserData\ %UserName%.

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

6. Click OK to complete the process.

Redirecting a Special Folder Based on Group Membership

You redirect a special folder to a single location by completing the following steps:

1. Access the Group Policy console for the site, domain, or organizational unit you want to work with.

2. In the User Configuration node, you'll find Windows Settings. Expand this entry by double-clicking it, and then select Folder Redirection.

3. Right-click the special folder you want to work with, such as Application Data, and then select Properties on the shortcut menu.

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

5. Click Add to display the Specify Group And Location dialog box. Or select an existing group entry and click Edit to modify its settings.

6. In the Security Group Membership field, type the name of the security group for which you want to configure redirection. Click Browse to find a security group to add.

7. In the Target Folder Location field, type the folder path to use. The folder you select is where the related data for the selected group is stored. The folder path should be set to a shared folder that is available on the network through a UNC path, such as \\Zeta\UserData. Click Browse to search for the folder in the Browse For Folder dialog box.

   Tip Normally, user data isn't stored separately. To specify that user data should be placed in subfolders that are specific to the user, add %UserName% to the path. For example, instead of setting the folder path to \\Zeta\UserData, you would use \\Zeta\UserData\%UserName%.

   

   Figure 4-5: Configure advanced redirection using the Security Group Membership panel.

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

Removing Redirection

Sometimes you may want to remove redirection from a particular special folder. You remove redirection by completing the following steps:

1. Access the Folder Redirection subnode in the Group Policy console.

2. Right-click the special folder you want to work with, and then select Properties on the shortcut menu.

3. Select 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 or Redirect The Folder Back To The Local Userprofile Location When Policy Is Removed. If you select the first option, files and folders remain in the redirected location even when redirection is removed. If you select the second option, files and folder are moved back to their local userprofile location.

4. If you changed the Policy Removal option, click Apply. Then select the Target tab. Otherwise just select the Target tab.

5. To remove all redirection definitions for the special folder, use the Setting selection list to choose No Administrative Policy Specified.

6. To remove redirection for a particular security group, select the security group in the Security Group Membership panel and then click Remove.

7. Click OK.

Using Administrative Templates to Set Policies

Administrative templates provide easy access to registry-based policy settings that you may want to configure.

Viewing Administrative Templates and Policies

As Figure 4-6 shows, a default set of administrative templates is configured for users and computers in the Group Policy console. 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).

Figure 4-6: Policies are set through administrative templates.

You can view the currently configured templates in the Group Policy console's Administrative Templates node. 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 additional templates containing new policies in the Group Policy console and 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 can be edited or created 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 Group Policy console. As you browse the templates, you'll find that policies are in one of three states:

• Not Configured The policy isn't used and no settings for it are saved in the registry.

• Enabled The policy is actively being enforced and its settings are saved in the registry.

• Disabled The policy is turned off and isn't enforced unless overridden. This setting is saved in the registry.

Enabling, Disabling, and Configuring Policies

You can enable, disable, and configure policies by completing the following steps:

1. Access the Group Policy console for the site, domain, or organizational unit you want to work with.

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

3. In the left pane, click the subfolder containing the policies you want to work with. The related policies are then displayed in the right pane.

4. Double-click or right-click a policy and choose Properties to display its related properties dialog box.

5. Click the Explain tab to see a description of the policy. The description is only available if one is defined in the related .adm file.

   To set the policy's state, click the Policy tab and then use the radio buttons provided to change the state of the policy:

   • Not Configured The policy is not configured.

   • Enabled The policy is enabled.

   • Disabled The policy is disabled.

   Note: Computer policies have precedence in Windows 2000. So, if there is a conflict between a computer policy setting and a user policy setting, the computer policy is the one that is enforced.

6. If you enabled the policy, set any additional parameters specified on the Policy tab, and then click Apply.

7. Use the Previous Policy and Next Policy buttons to manage other policies in the current folder. Then configure them in the same way.

8. Click OK when you're finished managing policies.

Adding or Removing Templates

You can add or remove template folders in the Group Policy console. To do this, complete the following steps:

1. Access the Group Policy console for the site, domain, or organizational unit you want to work with.

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

3. To add new templates, click Add. Then, in the Policy Templates dialog box, click the template you want to add and click Open.

   

   Figure 4-7: You can use the Add/Remove Templates dialog box to add more templates or remove existing ones.

4. To remove an existing template, select the template to remove, and then click Remove.

5. When you're finished adding and removing templates, click Close.

User and Computer Script Management

With Windows 2000 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 new feature of Windows 2000 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 2000 ships with scripting engines for VBScript and JScript. Other scripting engines are also available.

Assigning Computer Startup and Shutdown Scripts

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, and/or organizational unit 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 Task Scheduler Wizard. See the "Scheduling Tasks" section of this chapter for details.

To assign a computer startup or shutdown script, follow these steps:

1. For easy management, copy the scripts you want to use to the Computer\ Scripts\Startup or Computer\Scripts\Shutdown folder for the related policy. Policies are stored in the %SystemRoot%\SYSVOL\domain\policies folder on domain controllers.

2. Access the Group Policy console for the site, domain, or organizational unit you want to work with.

3. In the Computer Configuration node, double-click the Windows Settings folder. Then click Scripts.

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

5. Click Show Files. If you copied the computer script to the correct location in the policies folder, you should see the script.

6. 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 Computer\ Scripts\Startup or the Computer\Scripts\Shutdown 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.

   

   Figure 4-8: Add, edit, and remove computer scripts using the Shutdown Properties dialog box.

7. 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 buttons to reposition scripts as necessary.

8. If you want to edit the script name or parameters later, select the script in the Script For list and then click Edit.

9. To delete a script, select the script in the Script For list, and then click Remove.

Assigning User Logon and Logoff Scripts

User scripts can be assigned in one of three ways:

• You can assign logon and logoff scripts as part of a group policy. In this way, all users that are members of the site, domain, and/or organizational unit execute scripts automatically when they log on or log off.

• You can also assign logon scripts individually through Active Directory Users And Computers console. In this way, you can assign each user or group a separate logon script. See Chapter 9 for details.

• You can also assign individual logon scripts as scheduled tasks. You schedule tasks using the Task Scheduler Wizard. See the "Scheduling Tasks" section of this chapter for details.

To assign a group policy user script, complete the following steps:

1. For easy management, copy the scripts you want to use to the User\Scripts\ Logon or the User\Scripts\Logoff folder for the related policy. Policies are stored in the %SystemRoot%\SYSVOL\domain\policies folder on domain controllers.

2. Access the Group Policy console for the site, domain, or organizational unit you want to work with.

3. Double-click the Windows Settings folder in the User Configuration node. Then click Scripts.

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

5. Click Show Files. If you copied the user script to the correct location in the policies folder, you should see the script.

6. 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 User\Scripts\Logon or the User\Scripts\Logoff 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.

7. 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 buttons to reposition scripts as necessary.

   

   Figure 4-9: Add, edit, and remove user scripts using the Logon Properties dialog box.

8. If you want to edit the script name or parameters later, select the script in the Script For list and then click Edit.

9. To delete a script, select the script in the Script For list, and then click Remove.

Scheduling Tasks

When you manage systems, you'll often want to perform tasks like updates or maintenance during nonbusiness hours. This way, you don't affect productivity and workflow. But who wants to come in at 3 a.m. 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, Windows Script Host 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 in a log file.

Utilities for Scheduling Tasks

In Windows 2000, you can schedule tasks on local and remote systems using the Task Scheduler Wizard or the command-line AT scheduler. Each utility has its advantages and disadvantages.

Task Scheduler Wizard provides a point-and-click interface to task assignment. This makes it easy to quickly configure tasks 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.

Preparing to Schedule Tasks

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, 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 of Chapter 3 entitled "Configuring Service Startup" and "Configuring Service Logon."

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

Scheduling Tasks with Task Scheduler

You can use Task Scheduler to schedule tasks on the local or remote system to which you're currently connected. You access the Task Scheduler Wizard and currently scheduled tasks through the Scheduled Tasks folder.

Accessing the Scheduled Tasks Folder

You can access the Scheduled Tasks folder on a local system with either of the following techniques:

• Start Microsoft Explorer, double-click Control Panel, and then click Scheduled Tasks.

• Click Start, click Settings, click Control Panel, and then double-click Scheduled Tasks.

You can access the Scheduled Tasks folder on a remote system by completing the following tasks:

1. Start Explorer and then use the My Network Places node to navigate to the computer you want to work with.

2. Double-click the computer's icon and then double-click Scheduled Tasks.

Viewing and Managing Existing Tasks

As Figure 4-10 shows, entries in the Scheduled Tasks folder show currently scheduled tasks. You can work with entries in the Scheduled Tasks folder by completing the following steps:

1. Double-click Add Scheduled Task to start the Task Scheduler Wizard.

2. Double-click an existing task entry to view or change its properties. You can set advanced options through the Settings tab.

3. Select a task entry and press Delete to delete the task.

Creating Tasks with the Task Scheduler Wizard

To schedule a task with the Task Scheduler Wizard, follow these steps:

1. Start the Task Scheduler Wizard by double-clicking Add Scheduled Task in the Scheduled Tasks folder. Read the welcome dialog box and then click Next.

2. Using the dialog box shown in Figure 4-11, select a program to schedule. The dialog box shows key applications registered on the system, such as Disk Cleanup and Synchronize. The dialog box doesn't show available scripts, however. Click Browse to open the Select Program To Schedule dialog box. Use the dialog box to find a command-shell or WSH script you want to run.

   

   Figure 4-10: Existing tasks are available in the Scheduled Tasks folder. Click Add Scheduled Task to start the Task Scheduler Wizard.

   

   Figure 4-11: Select a program to run. Click Browse to find scripts and other applications.

3. Type a name for the task, as shown in Figure 4-12. The name should be short but descriptive so you can quickly determine what the task does.

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

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

   

   Figure 4-12: Type a name for the task, and then select a run schedule.

   

   Figure 4-13: Configuring a daily scheduled task.

   If you've selected a daily running task, the date and time dialog box appears as shown in Figure 4-13. Set a start time and date. Daily scheduled tasks can be configured to run

   • Every Day Seven days a week.

   • Weekdays Monday through Friday only.

   • Every … Days Every 2, 3, … N days.

   If you've selected a weekly running task, the date and time dialog box appears as shown in Figure 4-14. Configure the task using these fields:

   • Start Time Sets the start time of the task.

   • Every … Weeks Allows you to run the task every week, every 2 weeks, or every N weeks.

   

   Figure 4-14: Configuring a weekly scheduled task.

   

   Figure 4-15: Configuring a monthly scheduled task.

   • Select The Day(s) Of The Week Below Sets the day(s) of the week when the task runs, such as on Monday or on Monday and Friday.

   If you've selected a monthly running task, the date and time dialog box appears as shown in Figure 4-15. Configure the task using these fields:

   • Start Time Sets the start time of the task.

   • Day Sets the day of the month the task runs. For example, if you select 5, the task runs on the fifth day of the month.

   • The … Day Sets task to run on the Nth occurrence of a day in a month, such as the second Monday or the third Tuesday of every month.

   • Of The Month(s) These check boxes let you select which months the task runs on.

6. If you've selected One Time Only for running the task, the date and time dialog box appears as shown in Figure 4-16. Set the start time and start date.

7. With tasks that run when the computer starts or when the task's user logs on, you don't have to set the start date and time. The task runs automatically when the startup or logon event occurs.

   Tip If you want to configure a startup task for a specific user through the wizard, you'll need to log on as that user and then run the wizard.

8. After you've configured a start date and time, click Next to continue. Then type a username and password that can be used when running the scheduled task. This username must have appropriate permissions and privileges to run the scheduled task.

   

   Figure 4-16: Configuring a one time only scheduled task.

9. The final wizard dialog box 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 Explorer double-click the task to correct the problem in the related properties dialog box.

Scheduling Tasks with the At Utility

You can also control the Windows 2000 Task Scheduler service with the At utility. With At you can schedule tasks anywhere on the network and you don't have to log on to remote systems. You can set tasks to run once or periodically at a specific time.

Using the At Utility

To schedule tasks with At, you should be a member of the local Administrators group. Tasks are scheduled using a 24-hour clock where 12:00 is noon and 00:00 is midnight. The At utility doesn't automatically load the command interpreter before running built-in command-line utilities, such as DEL, COPY, or MOVE. You'll need to explicitly load cmd.exe at the beginning of a command. For example, if you wanted to copy c:\mydata\*.* to e:\backups\mydata, you would need to enter the following command:

AT 00:00 /every:M,T,W,Th,F "cmd /c copy /Q c:\mydata\*.* e:\backups\mydata"

When you work with programs and utilities that have separate executables, you don't have to start an instance of the command interpreter. You can work with the executable directly. Still, the executable must be in a directory accessible along the command path (the %PATH% environment variable). Here's how you could schedule a backup script to run every other day at 1 a.m.:

AT 01:00 /every:1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 backup.js

As you can see, when you use numeric dates you can use any value in the range 1–31. You schedule tasks to run relative to the current date as well. To do this, specify only a start time and not a run date. For example, to start a cleanup script at 3 a.m., you could use the following command:

AT 03:00 cleanup.js

You can also schedule tasks to run on the next occurrence of a day. For example, if today is Tuesday and you want the task to run on Friday, you could use the following command:

AT 08:10 /next:F update.vbs

Normally, scheduled tasks run as background processes. You can, however, set tasks to run interactively. To do this, use the /interactive switch, such as:

AT 03:00 /interactive /every:T,Th backup.vbs

Scheduling Tasks on Remote Systems

The AT command makes it easy to schedule tasks to run on remote systems. Simply type the UNC name of the computer before you specify other parameters. For example, if you wanted to schedule a task to run on a computer called PLUTO, you could type the following command at the command line on your system:

AT \\PLUTO 08:10 /next:F update.vbs

You could also use the Internet Protocol (IP) address of the computer, such as:

AT \\192.51.62.8 09:30 /every:M,W,F cleanup.js

Only use this option if the IP address is static.

Scheduling tasks on remote systems assumes that

1. You've configured the Task Scheduler service on PLUTO to use a logon with appropriate permissions.

2. The Task Scheduler service is running.

3. The scripts are located in directories that can be found along the path set for the service logon account.

Viewing Scheduled Tasks

You can view scheduled tasks on local and remote systems. On a local system, type AT on a line by itself and press Enter.

On a remote system, type AT followed by the UNC name of the system you want to examine:

At \\pluto

When you view tasks, the output you get is similar to the following:

Status    ID      Day            Time         Command Line
          1       Each M W F     3:00 AM      backup.vbs
          2       Each T Th      5:00 AM      cleanup.js
          3       Each Su        8:00 AM      update.js

The output tells you a lot about the scheduled tasks. You can determine

• Status Shows the status of each task. A blank entry indicates a status of OK. Otherwise, you'll see an error message, such as ERROR.

• ID Shows the unique identifier for each task.

• Day Shows when the task is scheduled to run. Recurring tasks begin with the keyword Each, such as Each M for every Monday. One-time tasks begin with the keyword Next, such as Next 3 for the next time it's the third day of the month.

• Time Shows the time the command is scheduled to run. Note that the time is displayed with an a.m. or p.m. indicator rather than the 24-hour clock used for scheduling tasks.

• Command Line Shows the command or executable run at the scheduled time.

You can use the status ID to display individual tasks, such as:

AT 2

Or

AT \\zeta 2

Deleting Tasks

You can use the ID number to delete tasks as well, or you can cancel all scheduled tasks. You delete a specific task as follows:

AT 2 /delete

Or

AT \\zeta 2 /delete

You cancel all tasks by typing the /delete switch without a task ID, such as:

AT /delete

Or

AT \\zeta /delete

Click to Order