Managing Day-to-Day Operations
This chapter discusses some of the tools that can help in the daily business of network management in Windows 2000 Server environments. The contens is taken with permission from Chapter 10 of the Microsoft Windows 2000 Server Administrator's Companion.
On This Page
Introduction
Using the Secondary Logon
Administration Tools
Support Tools
Microsoft Management Console Basics
Automating Chores with Scripts
Auditing Events
Delegating Control
Using Task Scheduler
Using the AT Command
Summary
Introduction
If it's true, as Mies van der Rohe said, that "God is in the details," then a network is a very holy place indeed. A network administrator's job consists of masses of details, and if you're to cope, you must find ways of handling and tracking them. Microsoft Windows 2000 supplies plenty of tools for this, including ones that allow you to delegate tasks to other users or groups, use scripts to automate tasks, and schedule tasks to run periodically. Nevertheless, administering a network is still largely a process of planning and organization, and in that area there's no substitute for brainpower.
Using the Secondary Logon
Recommended administrative practice dictates that an administrator be logged on to a privileged account (one with administrative rights) only while doing chores that require privileges. For ordinary work, the administrator is supposed to log off from the privileged account and then log on again to an ordinary account. Of course, it's not unusual that ten minutes later a situation arises requiring use of the privileged account. So then it's necessary to log off from the ordinary account and log back on to the administrator account, with the process reversed again a few minutes later.:
While logged on with administrative rights, choose RunAs Services from the Administrative Tools menu.
In the list of services, double-click RunAs Service.
Ensure that Startup Type is set to Automatic and that Current Status is set to Started. (If it isn't, click the Start button.) Click OK to close the dialog box..
Starting a Command-Line Window for Administration
With the RunAs service started, you can log on with your regular user account and then open a command shell for performing administrative tasks, as follows:
After logging on as a regular user, open a command window and enter the command runas /user:< domain\username > cmd. In this case, username is the account with administrative privileges. If you are logged on as a local user, the command is runas /user:< machinename\username > cmd.
A command-line window opens, and you're prompted for the password for the administrative account.
After you enter the password, a second window opens. As shown in Figure 10-1, the title bar of the window clearly indicates that it is running as the account selected.:
Right-click the taskbar and choose Task Manager from the menu.
Click the Processes tab. Highlight Explorer.exe, and click End Process. A warning message appears. Click Yes. The entire desktop, except for Windows Task Manager and any active applications, disappears.
Select the Applications tab in Windows Task Manager, and then click New Task.
In the Create New Task box, enter runas /user:< domain\username > explorer.exe. As before, username is the account with administrative privileges. If you're logged on locally, use the command runas /user:< machinename\username > explorer.exe.
Enter the password for the user name. The desktop, along with the taskbar, returns. This desktop is in the security context of the user name you specified in the command..
Administration Tools
Most of the tools you'll need for managing a Windows 2000 network come as part of the Windows 2000 Server and Windows 2000 Advanced Server packages, but only a few of them are automatically installed along with the operating system. Table 10-1 gives the complete list of Administration Tools.
Table 10-1. Administration Tools for Windows 2000
Installing Administration Tools Locally
To install the full set of Administration Tools locally, open the i386 folder on the Windows 2000 Server or Windows 2000 Advanced Server CD-ROM, and then double-click the Adminpak.msi file. This starts the Administration Tools Setup Wizard (Figure 10-2), which will install the tools (and later remove them and reinstall them, if you wish). Click Next and the installation proceeds.
Making Administration Tools Available Remotely
To make the Administration Tools available to others on your network, you can assign the tools to other computers or publish them in Active Directory. Chapter 24 covers the process of assigning and publishing to other users.
Support Tools
The Windows 2000 Support Tools are immensely valuable because they provide functionality not otherwise available in the operating system. You'll probably never use some of the tools, but a few will prove to be worth their weight in Microsoft stock options. This section discusses a few of these utilities. You can see a complete list by choosing Tools Help from the Windows 2000 Support Tools menu..
Network Connectivity Tester
Network connections can fail in a spectacular number of ways—at any number of servers and in a variety of client configurations. Determining the source of a problem can be a daunting process. Netdiag.exe can report on an equally spectacular number of functions, running tests on the DNS server, the WINS server, Kerberos, the bindings, the WAN, trust relationships, the IP configuration, the routing table, IPX, NetWare, DHCP, the default gateway, and more. Netdiag.exe can be run on Windows NT and Windows 95/98 as well as Windows 2000, so you can use this excellent troubleshooting tool on servers and clients alike.
Domain Manager
With Netdom.exe, most forms of domain management can be handled from the command line. Machine accounts can be added, removed, renamed, or moved to another domain. Netdom.exe also retrieves information about trusts and lets you establish trusts, synchronize the time, and verify secure channel passwords. The syntax for Netdom.exe is simple, but the range of possible parameters is extensive.
More Info Command syntax and examples are available in the Support Tools Help files. To find the syntax for a specific tool, open a command window and enter tool_name /?.
Active Directory Replication Monitor
Rather than merely monitoring low-level replication among servers, the Active Directory Replication Monitor (Replmon.exe) reports on a wide range of Active Directory functions. It displays the site topology while reporting on the server's properties, indicating whether it is a Global Catalog server, and listing its replication partners, its replication history, and the attributes replicated..
Disk Probe
Disk Probe (Dskprobe.exe) is indispensable when a critical hard disk goes bad. It is a sector editor that you can use to repair damaged partition tables, replace the master boot record, and repair or replace partition boot sectors. Even better, Disk Probe will save master boot records and partition boot sectors as files that can be used to restore the sectors if they become damaged in the future. This can be a great benefit because these data structures aren't part of the file system and are not backed up by any backup program. Table 10-2 briefly describes some of the Windows 2000 Support Tools. For a complete list, see Appendix F.
Table 10-2. Additional Windows 2000 Support Tools
Microsoft Management Console Basics
The Microsoft Management Console (MMC) is a powerful addition to the system administrator's arsenal. The MMC works as a packager of system tools, enabling the system administrator to create specialized tools that can then be used to delegate specific administrative tasks to users or groups. Saved as MMC (.MSC) files, these custom tools can be sent by e-mail, shared in a network folder, or posted on the Web. With system policy settings, they can also be assigned to users, groups, or computers. The tools are flexible enough to be modified, scaled up or down, and generally shaped for any use to which you might want to put them..
Click the Start button and select Run. In the Open text box, type MMC, and then click OK. An empty MMC window opens, as shown in Figure 10-3, ready for you to add snap-ins.Figure 10-3: . An empty MMC window.
From the Console menu, select Add/Remove Snap-in. (The menu commands on the menu bar at the top of the MMC window apply to the entire console.) The Add/Remove Snap-in dialog box opens. Here you can choose which snap-ins are in the console file as well as enable extensions. In the Snap-ins Added To box, accept the default, Console Root.
Click the Add button. This opens a dialog box listing the snaps-ins installed on your computer (Figure 10-4).Figure 10-4: . The Add Standalone Snap-in dialog box.
Highlight a snap-in to see a description of its function. Double-click a snap-in to add it to the console. For this example, we'll add Computer Management. The Computer Manager dialog box asks you to select the computer to manage (Figure 10-5).
Select the Local Computer option, and select the check box Allow The Selected Computer To Be Changed When Launching From The Command Line. These options are common to many of the snap-ins. Click Finish.
From the Add Standalone Snap-in dialog box, select Event Viewer, and click Add. As before, select the Local Computer option, and select the check box. Click Finish, then close the list of available snap-ins. The Add/Remove Snap-in dialog box lists two snap-ins: Computer Management (Local) and Event Viewer (Local).
Click the Extensions tab. By default, the box labeled Add All Extensions is checked, which means that when this console is opened on a particular machine, all extensions that are locally installed on that machine will be used. If this box isn't checked, only extensions that are selected on the list of available extensions will be loaded.
Click OK to close the Add/Remove Snap-in dialog box. The Console Root window now has two snap-ins, rooted at the Console Root folder.Figure 10-5: . The Computer Management dialog box for the Computer Management snap-in..
Customizing the Layout of a Console
Once you've added the snap-ins, you can provide different administrative views in the console by adding windows. To create one window for each of the snap-ins, follow these steps:
In the left pane of the console window, right-click the Computer Management folder and select New Window From Here. This opens a new Computer Management window rooted at the Computer Management snap-in.
In the Console Root window, right-click the Event Viewer folder and select New Window From Here. Click the Show/Hide Console Tree toolbar button in each window to hide the console tree (Figure 10-6).Figure 10-6: . The Show/Hide Console Tree button.
Close the original Console Root window. From the Window menu, choose Tile Horizontally. The console window should now look like Figure 10-7.Figure 10-7: . The console with tiled windows.
Note that the buttons and menus in each window apply only to that window. Remember to save your console file after completing the changes.
Setting Options for a Console File
When creating consoles for workgroup managers or other users, you may want to restrict how the console is used. Console options can be set so that users can access only the tools that the administrator allows. To set console file options, follow these steps:
With the console file open, click the Console menu and choose Options. This opens the Options dialog box.
Click the Console tab. Choose the console mode:
Author Mode No restrictions. The user can access all parts of the console tree as well as change this console file at will.
User Mode—Full Access The user can access all parts of the console tree but cannot make changes that affect functionality. Cosmetic changes, such as the arrangement of windows, are saved automatically.
User Mode—Limited Access, Multiple Window The user can access only the parts of the console that were visible at the time the console file was saved.
User Mode—Limited Access, Single Window The same as the previous mode, except that only one window is visible.
In all but Author mode, you can also select the Do Not Save Changes To This Console option, so that the console always opens in the same view.
Click OK and save the console file.
Modifying Console Files
After you've saved a console file in any mode other than Author mode, the Console menu is no longer visible, even to administrators. This prevents the user from changing the options. To modify a console file, open a command-prompt window and type mmc /a. The /a switch sets Author mode, overriding any User mode setting, and opens the console window, from which you can open any console file and make changes.
Note: The system administrator can set user profiles to disallow the use of the /a switch, and should do so to ensure that inappropriate modifications can't be made.
Distributing and Using Consoles
As mentioned earlier, the default location for saved console files is the Administrative Tools folder. Console files can be distributed in a variety of ways. You can copy a console file to a shared folder on the network, or you can mail it to another person by right-clicking the file, pointing to Send To, and selecting Mail Recipient. When you assign a console to be used by a particular person, be sure that the person's user profile includes permission to access the tools and services in the console. The user will also have to have any administrative permissions necessary to use the system components administered by the console.
If you know the location of a console, you can open it from Windows Explorer by clicking it as you would any other file. You can also open it from the command line. For example, to open the Fax Service console (which resides in a system folder) from the command line, type mmc % systemroot %\system32\faxserv.msc.
Using MMC for Remote Administration
MMC-based tools are admirably suited for remote administration. You can easily construct a console to administer a number of computers or a single machine. This section describes how to create a console that can be used to remotely administer a domain controller. The console will include the Services snap-in, which manages system services, and the Event Viewer snap-in, which allows access to the various event logs. To make this remote administration console, follow these steps:
Click the Start button, and then select Run. In the Open text box, type MMC, and then click OK. An empty MMC window opens.
From the Console menu, select Add/Remove Snap-in. The Add/Remove Snap-in dialog box opens.
Click Add to open the Add Standalone Snap-in dialog box.
Select Services, and then click Add.
In the This Snap-in Will Always Manage area, select Another Computer, and then click Browse. This will open another Select Computer dialog box.
Highlight the computer you want this snap-in to manage, and then click OK. Click Finish.
Repeat steps 4 through 6, except choose the Event Viewer snap-in. Close the Add Standalone Snap-in dialog box. Click OK in the Add/Remove Snap-in dialog box.
At this point, the console will look like the one in Figure 10-8. Save it under a descriptive name. You can use this console to view events on the remote machine and to start and stop services.
As you can see, consoles can be configured in dozens, if not hundreds, of different ways and then distributed. Snap-ins for every imaginable function will increasingly be available from Microsoft as well as third-party suppliers.
Note: Because consoles are excellent tools for organizing and delegating administrative chores, examples of their use can be found in many other chapters of this book.
Automating Chores with Scripts
Of necessity, most network administrators quickly acquire scripting skills. There aren't enough hours in the day to do everything manually, even if that were desirable. In addition, good scripts are like any program: once the information is entered correctly, there's no need to worry about it until something external changes.
Through ActiveX, Windows 2000 enables scripting options using Visual Basic, Scripting Edition (VBScript); JScript; or Perl. Previously, the only native scripting language supported by Windows was the MS-DOS command language, and many administrators will undoubtedly continue to use MS-DOS scripts because they're very small and very fast. Why use anything else if an MS-DOS script will do the job? The answer is that you shouldn't. However, in a large enterprise or for more complicated scripts, a more sophisticated scripting language is in order.
The Windows Script Host (WSH) is built into Windows 2000 and Windows 98. In addition, Windows 95 and Windows NT can run WSH, so scripts are portable across the Windows spectrum. Scripts run under WSH using Wscript.exe and Cscript.exe. Wscript.exe runs in the background, and Cscript.exe runs at the command prompt. To run a script from the command line, the syntax is
Cscript <scriptname.extension> [options] [arguments]
To view the entire list of host options, enter Cscript //? at a command prompt. The most important options are listed below.
//B Specifies batch mode; script errors and prompts are not displayed
//D Enables active debugging
//T: nn Indicates the maximum time in seconds that the script is permitted to run
Real World Uses for WSH WSH is useful for logon and logoff scripts that can be assigned to users—individually or as a group—or to computers. The other important use for WSH is the creation of user accounts, a tedious process at best and, in a large enterprise, quite impossible without scripts. Chapter 9 covers Group Policy objects and the creation of user accounts.
Auditing Events
Auditing certain computers, users, and operating system events is a necessary part of network administration. You choose what's to be audited and then, by reviewing the event logs, track usage patterns, security problems, and network traffic trends. Beware of the impulse to audit everything, however. The more events you audit, the bigger the logs. Reviewing huge event logs is a painful chore, and eventually no one looks at them anymore. Therefore, it's critical to decide on an auditing policy that protects your network without creating a large administrative burden. Also bear in mind that every audited event results in a small increase in performance overhead.
By default, all auditing categories are turned off when Windows 2000 is installed. Table 10-3 lists the categories of events that can be audited.
Table 10-3. Auditing categories
Every audited event tells you something, but it's not always something you need to know. For example, auditing successful logons and logoffs may reveal the use of a stolen password, or it may just produce endless pages showing that your duly authorized users are logging on and off as expected. Auditing logon failures, however, will definitely be rewarding if someone is trying a random password hack.
Before you can audit access to Active Directory objects (described in the next section), you must turn on the Audit Policy setting, using Group Policy. To do so, as well as to enable auditing of any of the other categories in Table 10-3, follow these steps:
Choose Active Directory Users and Computers from the Administrative Tools menu.
Right-click the domain name in the console tree, and choose Properties from the shortcut menu.
Click the Group Policy tab and then the Edit button.
In the left pane of the Group Policy console, click your way through Computer Configuration, Windows Settings, Security Settings, and Local Policies to reach Audit Policy (Figure 10-9).Figure 10-9: . Choosing categories of events to audit.
Right-click the event category you want to audit, and choose Security.
In the dialog box that opens, select the check box to define the setting, and select the option to audit successful and/or failed attempts.
Audit Settings for Objects
Assuming that you've turned on a policy setting for auditing an Active Directory object, you create audit settings by following these steps:
Right-click the object you want to audit, and choose Properties from the shortcut menu. Click the Security tab.
Click the Advanced button, and then click the Auditing tab (Figure 10-10).
Click Add to set up auditing for a new group or user. Make your selection and click OK.
In the Auditing Entry For Collwin dialog box (Figure 10-11), select the objects you want to audit from the Apply Onto drop-down list. Then, in the Access, select each type of access that you want audited. (Table 10-4 describes each event.) Click OK when you're finished.
Note: By default, audit settings are inherited by child objects. On the Auditing tab of the Access Control Settings for Collwin box (shown in Figure 10-10) is a check box for allowing inheritable auditing entries. Clear this box and the audit settings for this object will remain constant, even if the parent object's audit settings are changed. In addition, clearing the box will remove any audit settings that have already been inherited. The second check box on this tab resets existing auditing and allows audit entries to be inherited from the parent object once again.
Real World Auditing Cautions Windows 2000 allows such granularity that it's possible—no, easy—to create a real morass when selecting audit settings. So many items can show up in the event log that really important issues may be lost in the crowd. Be very careful when deciding what events need to be audited. Audit as few as is reasonable. You can always add events later as circumstances dictate.
Table 10-4. File system events that can be audited
Viewing Event Logs
Event logs must be viewed with regularity for auditing to have any effect. To view the security log, open Event Viewer from the Administrative Tools menu and then click Security Log. Double-click any entry to see more information about it. The security entries in Figure 10-12 are the result of one event. The folder was set to audit successful List Folder/Read Data events. One user opening the folder one time generated all the entries you see. Of course, you'll generally learn more from auditing failed events than from auditing successful ones, but this does demonstrate the need to choose one's auditing battles carefully.
Searching Event Logs
No matter how selective you are, the event logs will mix all sorts of information together, making searches for specific information difficult. To search for a specific type of event, highlight the log in Event Viewer, and choose Find from the View menu. In the Find dialog box (Figure 10-13), select the type or types of events you want returned. Table 10-5 describes the other options in the Find dialog box.
Filtering Event Logs
If you don't have enough specific information to locate what you need, you can filter an event log for certain types of information. To use event log filtering, follow these steps:
Choose Event Viewer from the Administrative Tools menu.
Right-click the log you want to search, and choose Properties from the shortcut menu.
Click the Filter tab. Table 10-5 describes the fields on this tab. Click OK when you're ready to start the filtering.
The log appears, filtered as you requested. To view the full, unfiltered log again, return to the Filter tab and click Clear.
Table 10-5. Options for filtering event logs
Setting the Size of Event Logs
When an event log is full, a dialog box will pop up to notify you. If this happens often, you may want to reduce the number of items being reported or increase the size of the log. To set event log options, follow these steps.
Choose Event Viewer from the Administrative Tools menu.
Right-click the log you want to configure and choose Properties.
On the General tab, set the options you want. Under When Maximum Log Size Is Reached, there are three options.
If you don't archive this log, choose Overwrite Events As Needed.
If you archive this log at regular intervals, you can select the Overwrite Events Older Than option. Fill in the appropriate number of days.
Do Not Overwrite Events, the last option, means that the log must be cleared manually. When the maximum log size is reached, new events will simply not be recorded.
Click OK when you're finished.
Real World Calling a Halt When the Log Is Full Maybe you are so security-conscious that none of the event log options are acceptable. If you absolutely, positively mustn't lose a single security event, you can set the computer to halt when the security log is full. A registry change is necessary to make this happen. First, set Event Log Wrapping to either Do Not Overwrite Events or Overwrite Events Older Than n Days. Then start RegEdit.exe and proceed to HKEY_LOCAL_MACHINE \SYSTEM \CurentControlSet \Control \Lsa \CrashOnAuditFail, and change the value to 1.
This setting will take effect after a reboot and then, when the log is full, the system will simply stop. After restarting, only administrators will be able to log on until the security log is cleared. This is a drastic measure, but it is necessary in some cases.
Archiving Event Logs
If you will be using event logs to track system usage trends, you must save them. To archive an event log, open Event Viewer from the Administrative Tools menu, and click the log you want to archive. Then, from the Action menu, choose Save Log As. If you save the file in the event log format (.EVT), it can be reopened in Event Viewer, and all the binary data for each event will be retained. You can also save logs as .TXT files or in comma-delimited format (.CSV), but in those cases the binary data isn't saved. Chapter 32 has details on using Event Viewer and the logs that are generated to learn more about the network and tune its performance.
Delegating Control
Obviously, one of the simplest ways to minimize your administrative chores is to delegate them. In a Windows NT network, the usual way to grant broad administrative rights is to make users members of the Domain Admins group. Or you can parcel out administrative rights through some combination of other groups such as Print Operators or Server Operators.
These groups are still available, but Windows 2000 makes delegation even simpler: it allows you to assign responsibility for management of some portion of the namespace to another user or group. The recipient of the delegated authority can have complete administrative control within the area chosen but not the sweeping administrative rights inherent in being a member of the Domain Admins group.
Assign control by organizational unit (OU) whenever possible, because assigning permissions at the object level quickly becomes too complicated to be worthwhile. Records of security assignments are critical, so keep track of all delegations. To delegate control, use the Delegation of Control Wizard, which always assigns permissions at the OU level. (Detailed descriptions of permissions are provided in Chapter 9. For more on the planning and deployment of security policies, see Chapters 17 and 18.) To use the wizard, follow these steps:
Open Active Directory Users and Computers from the Administrative Tools menu.
Double-click the domain node, and then right-click the container whose control you want to delegate and choose Delegate Control from the shortcut menu. This starts the Delegation of Control Wizard. Click Next.
Click the Add button to select the user or group to be granted control. Make your selection from the Select Users, Computers, or Groups screen (Figure 10-14).Figure 10-14: . Selecting the recipients of delegated control.
In the Tasks to Delegate screen, select the tasks that you want to delegate. Select predefined tasks or click Create a Custom Task. Click Next.
If you selected a predefined task, you're essentially finished. Review the summary and click Finished.
If you selected Create a Custom Task, you're presented with more specific choices as to what objects you're delegating control on and the specific permissions to be granted. When those choices are made, you'll see a summary of the delegation. Click Finished.
Using Task Scheduler
While it's true that you could—and still can—schedule tasks using the AT command, as described later in this chapter, Task Scheduler provides a graphical interface and is much easier to use. Tasks can be scheduled during off-hours and to run repeatedly. The Task Scheduler service is started at boot up and runs in the background. To use Task Scheduler, open Control Panel, double-click the Scheduled Tasks folder, and then follow these steps:
In the Scheduled Tasks window, double-click the Add Scheduled Task entry. This starts the Scheduled Task Wizard. Click Next.
Select a program from the screen (Figure 10-15), or click the Browse button to locate another program. Click Next.
Supply a name for the task, and then indicate how often you want it performed. Click Next.Figure 10-15: . Selecting the program to be scheduled.
Select the time of day you want the task performed. Depending on the timing you've selected, you'll also need to specify one of the following:
Daily Task Every day, every n days, or weekdays only.
Weekly Task Every n weeks; supply the day of the week.
Monthly Task Select the day of the month, and select which months.
Supply the user name and password for the user who will be scheduling tasks. Click Next. Note that the account you specify must have the privileges necessary to run the task. For example, if you're scheduling a backup program, the user must have backup rights.
If you need to specify parameters for the task being scheduled, select the check box next to Open Advanced Properties, and then click Next.
Make the necessary changes, and click OK.
Tip For tasks to run as expected, it's important that the computer's date and time be set correctly.
Many programs will start to run in Task Scheduler and then pause, waiting for input that never comes—or that comes much later, when someone looks at the machine to see what's going on. To make sure you have all of the parameters for a task to be able to run successfully, open a command prompt and type program_name /?. Then right-click the task in the Scheduled Tasks window and choose Properties. Enter the necessary parameters in the Run text box and click OK.
You might want to schedule a task to run right away so you can test its performance. If a task is scheduled by a user and that user isn't logged on at the scheduled time, the task still runs but is in the background and not visible.
Changing a Schedule
Even the best schedule can run up against reality now and again, so you need to be able to adjust your planned events.
To run a task immediately, right-click the task's icon in the Scheduled Tasks window and choose Run from the shortcut menu.
To stop a task that's running, right-click the task's icon in the Scheduled Tasks window and choose End Task. If the scheduled task has been set up to start another task, the End Task command will halt only the original scheduled task.
To temporarily halt all Task Scheduler actions, open the Advanced menu in the Scheduled Tasks window and choose Pause Task Scheduler. Any tasks that do not start because Task Scheduler is paused will run again only at their next scheduled time. To start Task Scheduler up again, click the same menu and choose Continue Task Scheduler.
To stop using Task Scheduler, open the Advanced menu in the Scheduled Tasks window and choose Stop Using Task Scheduler. No scheduled tasks will run, and the Task Scheduler service will no longer start automatically when the system is rebooted.
Tracking Task Scheduler
The system maintains a detailed log of Task Scheduler's activities. To view the log, double-click Scheduled Tasks in Control Panel. From the Advanced menu, choose View Log. This opens a log like the one shown in Figure 10-16, with the most recent entry at the bottom of the window. The Details view in the Scheduled Tasks window displays information about each task (Figure 10-17).
If a scheduled task doesn't execute as expected, right-click the task in the Task Scheduler window and choose Properties from the shortcut menu. Verify that the task is in fact enabled. (The Enabled check box in the Task Properties window should be selected.)
Viewing Tasks on a Remote Computer
If you are an administrator of a remote computer running Windows NT or Windows 2000, you can view and edit the Task Scheduler settings on that computer. Find the computer in the My Network Places window ( in Windows 2000) or in the Network Neighborhood window (in Windows NT), and then double-click the Scheduled Tasks folder.
To view and edit scheduled tasks on computers running Windows 95 or later, the remote computer must
Have remote administration enabled
Specify your user account as having remote administrative access
Share the hard disk on which the Scheduled Tasks folder resides
Real World Autocompletion on the Command Line The command line may be moribund, but it's far from dead. Windows 2000 includes actual improvements in command-line functions, such as file and folder autocompletion. To turn this feature on, open a command-line window and type cmd /f:on. Now you can avoid typing long file or folder names at the command line. For example, to navigate into the Program Files folder from the root of the system drive (typically C:\), you'd type c:\cd p and then press Ctrl+D. The command will expand immediately to c:\cd "Program Files". Press Enter to invoke that path.
The feature will also work with files. Let's say you're in C:\Program Files\Windows Media Player and you would like to execute Mplayer.exe. At the command line, type mp and then press Ctrl+F. The path will expand to include Mplayer.exe. Press Enter to actually execute the file.
For the full documentation, open a command window and type help cmd.
Using the AT Command
You can also use the AT command to schedule tasks. By default, the AT command is run using the LocalSystem account, which requires administrative privileges. To specify another account as the user of the AT command, follow these steps:
Open Control Panel and double-click Scheduled Tasks.
In the Scheduled Tasks window, open the Advanced menu and then choose AT Service Account.
Click This Account and specify a particular user and password. Click OK.
AT Command Syntax
The command structure for the AT command is as follows:
AT [\\computername] [id] [[/delete]|/delete [/yes]] AT [\\computername] time [/interactive] [/every:date[,…] | /next:date[,…]] command
The following parameters can be used with the AT command. Used without parameters, the AT command returns a list of scheduled commands.
\\computername Specifies a remote computer. Without this parameter, the local computer is assumed.
id Indicates the identification number, if one is assigned.
/delete Cancels a scheduled command. If no identification number is specified, all scheduled commands on the computer will be canceled.
/yes Forces a yes answer to all system queries when canceling all commands.
time Specifies when the command is to run, expressed as hours:minutes in 24-hour notation.
/interactive Allows the task to interact with the desktop of the user logged on at the time the job is run.
/every: date [,...] Runs the command on the date specified. The date can be specified as one or more days of the week (M, T, W, Th, F, S, Su) or as one or more days of the month (numbers 1 through 31). Separate multiple dates with commas. If this parameter is omitted, the current day of the month is assumed.
/next: date [,...] Runs the command on the next occurrence of the specified day. If this parameter is omitted, the current day of the month is assumed.
command Indicates the program, batch file, or command to be run. If a path is required, use the Uniform Naming Convention (UNC) path.
Here are some important facts to keep in mind about the AT command:
The AT command doesn't automatically load Cmd, the command interpreter, so if the command parameter doesn't point to an executable file, you must explicitly specify Cmd, followed by the /c switch, at the beginning of the command.
Commands scheduled using AT run as background processes, so there is no displayed output. To redirect output to a file, use the redirection symbol (>). The redirection symbol must be preceded by the escape symbol (^), so a sample command would be at retrieve.bat ^>c:\daylog.txt.
If you have to use a drive letter to connect to a shared directory, include an AT command to disconnect the drive when the task is completed. Otherwise, the assigned drive letter will be neither available nor seen at the command prompt.
Note: You can switch back and forth between the AT command and Task Scheduler, although there are some limitations. For example, if you schedule a task using AT and later modify that same task using Task Scheduler, the task is then "owned" by Task Scheduler and you can no longer access it using AT.
Summary
Windows 2000 supplies plenty of tools to help in the management of daily operations, including ones that handle delegation, scripts, and task scheduling. However, it's still up to the humans to do the planning and decide which tools are appropriate for which chores. Every network has its own quirks and needs, and only experience can show you the optimal path. The next chapter covers the basics of installing and using Active Directory.
For More Information
Chapter 10 of the Microsoft Windows 2000 Server Administrator's Companion (ISBN: 1-57231-819-8) is reprinted with permission from Microsoft Press. For more information, go to.
The practical guide to planning, deployment, and maintenance—straight from the experts
Get up to speed fast on the new operating system with the essential everyday resource for anyone who needs to install, configure, and maintain Windows® 2000 Server.