Managing Day-to-Day Operations

By Charlie Russel and Sharon Crawford

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.

After a few days of this, even the most security-conscious person begins to toy with the idea of logging on to the administrator account and staying there. And in time, most administrators succumb to the temptation and stay in the privileged account most of the time.

This practice makes Microsoft Windows NT systems highly susceptible to "Trojan horse" attacks. Just running Microsoft Internet Explorer and accessing a nontrusted Web site can be very risky if done from an administrator account. A Web page with Trojan code can be downloaded to the system and executed. The execution, done in the context of administrative privileges, will be able to do considerable mischief, including such things as reformatting a hard disk, deleting all files, or creating a new user with administrative access. When you think about it, it's like handing the keys to your network to a complete (and malicious) stranger.

This problem is finally addressed in Windows 2000 with the RunAs service. This service enables you to work in a normal, nonprivileged account and still access administrative functions without logging off and then logging back on again. To set up the RunAs service, follow these steps:

1. While logged on with administrative rights, choose RunAs Services from the Administrative Tools menu.

2. In the list of services, double-click RunAs Service.

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

   After performing these steps, create an ordinary user account for your own use (if you don't have one already). Make sure that the user account has the right to log on locally at the machine you want to use.

Note: Windows 2000 views all domain controllers as special cases. On a domain controller, for example, all management of users and groups must be done through the Active Directory Users and Computers snap-in. Also, by default, users can't log on locally to a domain controller. Chapter 9 has more on creating user accounts and granting rights.

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:

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

2. A command-line window opens, and you're prompted for the password for the administrative account.

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

Figure 10-1: . A command-line window for an administrator account.

You can perform any command-line tasks you want from this window. Of course, there are some administrative tasks that can't be done from the command line or that can be done only with great difficulty. Some applications, such as Control Panel and the Printers folder, are launched from the shell at the time of logon, so if you're logged on as an ordinary user, the Control Panel functions stay in that context.

To stop the shell and start it again as an administrator so that you can use functions like Control Panel, follow these steps:

1. Right-click the taskbar and choose Task Manager from the menu.

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

3. Select the Applications tab in Windows Task Manager, and then click New Task.

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

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

To return to the ordinary user's desktop, use Task Manager to shut down Explorer.exe again. Then start a new instance by typing explorer.exe (without runas, so that Internet Explorer is restarted in the original security context) in the Create New Task dialog box.

Caution: Don't close Task Manager while you're working in the desktop's administrative context—just minimize it to the taskbar. Closing Task Manager can produce unpredictable results and is likely to cost you more time than you can possibly save by using RunAs.

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

Tool Name	Description
Active Directory Domains and Trusts	Administers domain trusts, changes the domain mode, adds and changes user principal name suffixes
Active Directory Sites and Services	Establishes and administers sites, replication, and security services
Active Directory Users and Computers	Manages users, computers, and groups within a domain
Certification Authority	Manages Certificate Services, which issues certificates for public key security
Cluster Administrator (Advanced Server only)	Handles the configuration of clusters and nodes
Component Services	Configures and administers Component Object Model (COM) components and applications
Computer Management	Administers disks, shares, users, groups, and services on the local computer
Configure Your Server	Sets up and configures Windows services
Connection Manager Administration Kit	Manages and customizes local and remote connections
Data Sources	Adds, removes, and configures Open Database Connectivity (ODBC) databases and drivers
DHCP	Manages Dynamic Host Configuration Protocol (DHCP) services
Distributed File System	Manages Distributed file system (Dfs) installation, topology, and replication
DNS	Manages DNS services
Event Viewer	Displays application, security, and system notification logs
Internet Authentication Service	Configures security and authentication for dial-in users
Internet Services Manager	Manages Internet Information Services (IIS)
Licensing	Manages client licenses
Local Security Policy	View and configure user rights, audit policy and other security settings for the local computer.
Network Monitor	Captures frames of network data for detection and analysis of network problems
Performance	Views system performance graphs; configures performance logs and alerts
Admission Control QoS (Quality of Service)	Assigns network bandwidth by subnet
Remote Storage	Manages the storage of infrequently accessed files
Routing and Remote Access	Administers dial-up, virtual private networking, and internetwork connections
Server Extensions Administrator	Manages Front Page server extensions
Services	Starts, stops, and configures services
Telephony	Manages telephony clients and servers
Telenet Server Administration	Starts, stops, and returns information about Telenet Server.
Terminal Services Client Creator	Makes floppy disks for installing Terminal Service client software.
Terminal Services Configuration	Configures new connections for Terminal Services; modifies and deletes existing connections
Terminal Services Manager	Displays terminal servers in trusted domains
WINS	Administers WINS

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.

Figure 10-2: . The first screen of the Administration Tools Setup Wizard.

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.

If you don't see the Support Tools on your Programs menu, you'll need to install them. To install the Windows 2000 Support Tools, insert the Windows 2000 CDROM. Open the Support folder and then the Tools folder. Double-click Setup.

Note: The tools provided on the Windows 2000 CD-ROM are a subset of the tools you can get by purchasing the full Microsoft Windows 2000 Server Resource Kit. The Resource Kit is a separate product with its own companion CD, available from Microsoft Press.

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.

The units of replication among domain controllers are directory partitions that must contain the most current information about objects in the domain. If a server is down or the network is disrupted, the information may not be completely up-to-date. The Replication Monitor can synchronize a monitored server with a specific replication partner to get everything back in order. It also generates status reports for servers throughout a forest for troubleshooting replication errors.

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

Tool	Filename	Format	Description
ADSI Edit	Adsiedit.msc	GUI	Low-level editor for Active Directory; enables adding, moving, and deleting objects within Active Directory.
Dependency Walker	Depends.exe	GUI	Scans any Win32 module and reports all dependent modules. Used to find the minimum set of files needed to load an application and to find what functions a module uses or exports.
Distributed file system utility	Dfsutil.exe	Cmd	Queries and troubleshoots Dfs.
DNS Troubleshooting Tool	Dnscmd.exe	Cmd	Allows you to view and modify DNS servers, zones, and resources.
Global Flags Editor	Gflags.exe	GUI	Edits global registry settings or flags in use by the kernel.
Memory Profiling Tool	Memsnap.exe	Cmd	Takes a snapshot of all of the memory resources being used by all processes and reports the information to a log file.
Registry Console Tool	Reg.exe	Cmd	Modifies the registry database from the command line. Used to query, add, delete, copy, save, and restore entries.
Remote Command Line	Remote.exe	Cmd	Runs command-line programs on remote computers using named pipes only.
Security Administration Tools	Sidwalk.exe Showaccs.exe Sidwalk.msc	Cmd/ Cmd/ GUI	Manage access control lists.
SNMP Query Utility	Snmputilg.exe	GUI	Graphical version of Snmputil.exe used to troubleshoot Simple Network Management Protocol (SNMP).

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.

To build a custom tool, you can either start with an existing console and modify it or start from scratch. In a mature network, you'll most likely use the former method, taking predefined consoles and adding or subtracting snap-ins.

Creating an MMC-Based Console with Snap-ins

Building your own tools with the MMC's standard user interface is a straightforward process. The next few sections walk you through the creation of a new console and describe how to arrange its administrative components into separate windows.

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

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

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

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

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.

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

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

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

Save the console by choosing Save from the Console menu. You will be prompted for a name—be as descriptive as possible. The file is saved in the Administrative Tools folder by default. This folder is part of your profile, so an added benefit is that if you use roaming profiles, any tools you create will go with you. See Chapter 9 for information on creating roaming profiles.

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:

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

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

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

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

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

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

1. Click the Start button, and then select Run. In the Open text box, type MMC, and then click OK. An empty MMC window opens.

2. From the Console menu, select Add/Remove Snap-in. The Add/Remove Snap-in dialog box opens.

3. Click Add to open the Add Standalone Snap-in dialog box.

4. Select Services, and then click Add.

5. In the This Snap-in Will Always Manage area, select Another Computer, and then click Browse. This will open another Select Computer dialog box.

6. Highlight the computer you want this snap-in to manage, and then click OK. Click Finish.

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

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

Figure 10-8: . A console for remote administration.

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

Event Category	Description
Account logon events	Activated when a domain controller receives a logon request
Account management	Activated when a user account or group is created or changed
Directory service access	Activated when an Active Directory object is accessed
Logon events	Activated when a user logs on or logs off
Object access	Activated when an object is accessed
Policy change	Activated when a policy affecting security, user rights, or auditing is modified
Privilege use	Activated when a user right is used to perform an action
Process tracking	Activated when an application executes an action that is being tracked
System events	Activated when a computer is rebooted or shut down or another event occurs that affects security

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:

1. Choose Active Directory Users and Computers from the Administrative Tools menu.

2. Right-click the domain name in the console tree, and choose Properties from the shortcut menu.

3. Click the Group Policy tab and then the Edit button.

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

5. Right-click the event category you want to audit, and choose Security.

6. 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:

1. Right-click the object you want to audit, and choose Properties from the shortcut menu. Click the Security tab.

2. Click the Advanced button, and then click the Auditing tab (Figure 10-10).

3. Click Add to set up auditing for a new group or user. Make your selection and click OK.

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

Figure 10-10: . Selecting a group or user or computer to be audited in connection with an object.

Figure 10-11: . Selecting the specific events you want audited.

Table 10-4. File system events that can be audited

Event	Activated When
Traverse Folder/Execute File	A folder is traversed (that is, someone passes through the folder on the way to a parent folder or a child folder) or an application is run
List Folder/Read Data	A folder is opened or data is viewed in files
Read Attributes	The attributes of a file or folder are viewed
Read Extended Attributes	Extended attributes (defined and created by programs) of a file or folder are viewed
Create Files/Write Data	A file is created inside a folder or a file is changed, overwriting existing information in the file
Create Folders/Append Data	A folder is created inside the folder being audited or information is added to an existing file
Write Attributes	A file or folder attribute is changed
Write Extended Attributes	Extended attributes (defined and created by programs) of a file or folder are changed
Delete Subfolders and Files	A file or subfolder is deleted
Delete	A specific file is deleted
Read Permissions	Permissions for a file or folder are viewed
Change Permissions	Permissions for a file or folder are modified
Take Ownership	Ownership of a file or folder changes

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.

Figure 10-12: . Viewing the security log.

Figure 10-13: . Searching for specific events in a log.

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:

1. Choose Event Viewer from the Administrative Tools menu.

2. Right-click the log you want to search, and choose Properties from the shortcut menu.

3. Click the Filter tab. Table 10-5 describes the fields on this tab. Click OK when you're ready to start the filtering.

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

Option	Use to Search or Filter For
Information	Notification that some major operation has been performed successfully.
Warning	Notification of some problem or potential problem. Warnings may or may not be significant. For example, replication performed after repeated tries will generate a warning.
Error	Notification of an important event. Errors signify a loss of data or a loss of function. For example, failure of a service to start during boot up will generate an error.
Success Audit	Events audited for success.
Failure Audit	Events audited for failure.
Event Source	A source for an event, such as a system component or a program.
Category	Events by category, such as logon/logoff, policy change, or process tracking.
Event ID	The specific ID number assigned to each logged event.
User	A specific user.
Computer	A specific computer.
From	Events after a specific date. The default is the first date in the log. You can click the drop-down box to select events on a specific date.
To	Events before a specific date. The default is the last date in the file.

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.

1. Choose Event Viewer from the Administrative Tools menu.

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

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

1. Open Active Directory Users and Computers from the Administrative Tools menu.

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

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

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

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

1. In the Scheduled Tasks window, double-click the Add Scheduled Task entry. This starts the Scheduled Task Wizard. Click Next.

2. Select a program from the screen (Figure 10-15), or click the Browse button to locate another program. Click Next.

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

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

5. If you need to specify parameters for the task being scheduled, select the check box next to Open Advanced Properties, and then click Next.

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

Figure 10-16: . The Task Scheduler log.

Figure 10-17: . The Details view for scheduled tasks.

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:

1. Open Control Panel and double-click Scheduled Tasks.

2. In the Scheduled Tasks window, open the Advanced menu and then choose AT Service Account.

3. 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 https://www.microsoft.com/mspress/.

Click to order

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.