Systems administrators are firefighters, running from one problem to the next, occasionally stopping long enough to do some advance planning. Whether you're new to Windows NT or you're a veteran systems administrator, you need all the tools and knowledge you can get your hands on to keep your systems up and running and your users happy. However, most systems administrators don't have time to scan hundreds of books, Web sites, and newsgroups to keep up with the ever-changing technology. (For a few tips about where to find good NT resources, see the sidebar, "Leads to NT Resources".) The following tools and tips can help you better use your time. With these suggestions, you can start to build a foundation of resources to help you become a more effective and valuable NT systems administrator.
Resource Kit Tools
Microsoft Windows NT Workstation Resource Kit and Microsoft Windows NT Server Resource Kit for NT 4.0 are must-haves in the systems administrator's arsenal. The NT Server resource kit's CD-ROM includes all the utilities on the NT Workstation resource kit's CD-ROM plus more than 30 server-specific utilities. The NT Workstation resource kit's documentation is more complete regarding workstation issues. (For a review of both resource kits, see Jonathan J. Chau, "Resource Kit Review," March 1997.)
The biggest challenge about using the resource kits is remembering all the utilities the kits provide when you need them. (For an overview of the utilities in the NT Server resource kit, see Michael D. Reilly, "Windows NT 4.0 Resource Kit Utilities,".) Most systems administrators find that command-line utilities are valuable when you need to perform changes concurrently to many systems. Here are a few command-line tools that I've found indispensable.
RCMD and RCMDSVC. Install the remote command (RCMD) service on all your NT workstations and servers. With the client command-line program, RCMD, you can get a command line on any box running this service. You can connect to and quickly issue commands on remote machines. For example, you can issue a NET START command to verify that a service is up and running, an IPCONFIG command to view TCP/IP configuration information, or an AT command to schedule a job.
Installing the NT Server resource kit sets up the client program. You install and run the server program, RCMDSVC, as a service. On the Services tab of the Network applet in Control Panel, choose Add, then choose Have Disk. Enter the path to your resource kit files. You use the oemnsvrc.inf file to set up the RCMD service.
After you install the RCMD service on all your NT machines, you can create scripts to effect changes on multiple machines. For example, the command
rcmd \\<servera> net stop schedule
connects to servera, stops the Schedule service, and then returns. You can write a batch file to perform this action for multiple machines, and then use the AT command to schedule the batch file's execution at a later time.
The RCMD service installed on each remote machine runs under the security context of the LocalSystem account. The LocalSystem account has Administrator status on the local system, but no access to network resources. Consequently, tasks launched by the RCMD service cannot access network resources. For example, you cannot use RCMD to remotely perform a NET USE command to a network share. However, because the LocalSystem account has rights to do almost everything else on the local system, you can perform remote changes that would not run if a regular user account launched them.
SC. The SC, or Service Controller utility, is a handy tool for scripting changes to service configurations. You can use SC to start and stop services, to change the user account or password that a service employs on startup, to change a service's startup type (e.g., from automatic to manual), or to delete a service from a machine. With RCMD, you can use SC to manipulate services on remote machines.
Perhaps the handiest feature of SC is its ability to change the user account and password that a service uses on startup. For example, suppose that on a large number of machines you install a service that starts with a domain user account. To change the password for this account, you typically must visit each machine's service controller. With SC and RCMD, you can script this change for multiple machines. For instance, if you want to change the password on the Internet Information Server (IIS) service running on a machine, you use SC in the following way:
sc config "World Wide Web Publishing Service" password= newpass
Like many other resource kit utilities, the SC command is very sensitive to correct syntax. For example, take this password option: If you don't insert a space between the equal sign and newpass, the command fails, without an error message.
WINSCL. If you work in a TCP/IP-based NT environment, you probably use Windows Internet Name Service (WINS). The WINSCL utility is a command-line tool for accessing and changing the WINS database. WINSCL is the ideal tool for deleting individual corrupted records or groups of corrupted records from a WINS database, but WINSCL can do a lot more. You can change configurations of WINS servers, manually add records to the database, and list the contents of the database. The most useful feature is WINSCL's ability to delete corrupted entries.
The WINSCL tool is finicky about syntax: Options are case sensitive (usually uppercase), and they often do not respond as you expect them to. For example, to delete a record using WINSCL's DRR option, you need to add a zero and a space before the version number of the record you want to delete. The WINS version ID consists of a low-order version number and a high-order version number. Most WINS databases do not contain enough records to require the high-order bits, so the high-order version number defaults to zero. The WINS Administrator doesn't show the zero, but WINSCL expects it. Furthermore, the WINS Administrator displays record versions in hexadecimal format, but WINSCL expects decimal format. Thus, to delete a record with a version ID of hexadecimal 30B56, you must enter
0 199510
Missing in Action. Unfortunately, some files are missing from the NT 4.0 resource kits, and users have experienced problems with some of the tools. For instance, the resource kits document the GLOBAL and LOCAL utilities, but the CD-ROM doesn't contain them. The Telnet service in the resource kits includes an incorrect oemsetup.inf file. This file installs only one of the two necessary services associated with the Telnet service. Microsoft has posted updates to these and other utilities, including a new oemsetup.inf for the Telnet service. You can find these updates at Microsoft's ftp site, ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt40.
Built-in Tools
Within NT you can find useful commands and utilities for solving common problems. However, with so many commands and options, remembering which command meets which need is difficult. Fortunately, NT's online Help provides information about the commands, their parameters, and syntax.
Here's an example of the type of Help NT's command-line tools can provide. Suppose you need to update files on a server, but you find that some clients are using those files, thereby rendering the files unavailable for update. You can free up those in-use files by deleting the share the users connect to. However, this strategy knocks everyone off the share and frees up all files, including some that might not need to be freed up. This strategy also often leaves the client machines in an unknown state, which can cause other problems.
Next time, instead of deleting the share, try using the NET FILE command. If you issue this command on the server where the files are in use, you can get a list of open files, who has the files open, and the file handle numbers. If you pipe this list to a file and use a utility such as DOS's FINDSTR command, you can identify the file handles of the files you want to close. Then, reissue the NET FILE command, except use
net file <filehandle#> /close
for each open handle you want to close. Using this command, you affect only the files you want to update, rather than all files and users connected to the share. You might still have to deal with some client application errors, but the number of affected workstations will be smaller.
Administrative Tools. NT also provides a set of built-in Administrative Tools that you can access from Start, Programs. (For a concise overview of NT's default Administrative Tools, see Ed Tittel and James Michael Stewart, "Systems Management Tools," May 1997.) When you manage a large NT environment, no NT tool is more valuable than Performance Monitor. It provides realtime charting, historical logging, alerting, and reporting on almost every major system and application component running on your NT servers and workstations. You can use Performance Monitor for troubleshooting day-to-day problems or for capacity planning. (For detailed information about Performance Monitor, see Michael D. Reilly, "The Windows NT Performance Monitor," March 1997, and, "More Windows NT Performance Monitor," April 1997.)
For example, if you suspect an application or service has a memory leak, check the Working Set counter under the Memory object. Highlight the suspect process, and watch it run. If the Working Set counter steadily increases over time, you might have a memory leak.
Want to send an email to all systems administrators when available disk space on several servers drops below 10 percent? Use Performance Monitor's Alerting feature, which lets you launch a program when an alert threshold is met. For example, you can launch a command-line email or pager utility that alerts you when a threshold is crossed.
If you want Performance Monitor to do logging or alerting on a large number of NT servers or workstations, investigate the Datalog service that comes with the NT Server resource kit. Datalog lets you run Performance Monitor as a service on any number of servers. Datalog keeps all log files on the local server, and you can grab and view them as needed. Datalog has one quirk concerning the way you configure the Performance Monitor workspace: Each machine that runs Datalog needs a unique workspace file, which includes the machine name to monitor and the objects and counters to log or alert.
The SDK
Microsoft scatters bits and pieces of useful functionality throughout its product line, in places you might not look. The Win32 software development kit (SDK) is an example--it's a good source for useful systems administrator tools. Recently, I was looking for a command-line utility that provided functionality similar to UNIX's which command. I wanted to search the path on a given machine for every occurrence of a file to identify the presence of duplicate copies. In the SDK, I found the where command, which performed this function perfectly.
In the SDK, you can find several other developer troubleshooting tools that you might find useful in your systems administration tasks. For example, WPERF presents a graphical view of key memory counters on a given system, as shown in Screen 1.
Mucking with the Registry
The Registry is one of the best administrative features of NT. You can find all the configuration information for a system in one place, which you can access locally or remotely. To be an effective administrator, you owe it to yourself to get familiar with what's in the Registry, how to change it, and the consequences of your changes. (For more information about the Registry, see Christa Anderson, "Care and Feeding of the Registry," December 1996, and Mark Russinovich, "Inside the Windows NT Registry," April 1997).
The Registry hives are files kept in the %systemroot%\system32\config directory. The hives you'll spend the most time with are HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. Registry permissions prevent nonadministrative users from doing much with HKEY_LOCAL_MACHINE. However, as an administrator, you have several tools you can use to edit the Registry. In addition to NT's REGEDIT and REGEDT32, the resource kits provide many tools for manipulating the Registry from the command line or within scripts. For example, the REGINI utility lets you make multiple Registry changes at one time. The utility inputs references to key names and their required values from a .ini file (make sure you include a carriage return at the end of the .ini file, or REGINI will fail) and subsequently edits the Registry. For example, the following REGINI file changes the startup type of the Schedule service from manual to automatic and enables the TCP/IP option for DNS lookup of NetBIOS machine names:
\Registry\machine\system\CurrentControlSet\Services\Schedule
Start = REG_DWORD 2
\Registry\machine\system\CurrentControlSet\Services\NetBT\Parameters
EnableDNS = REG_DWORD 1
The resource kits for NT 4.0 contain several other command-line utilities for making scripted Registry changes. You can use REGDEL to delete local or remote Registry keys, REGCHG to change Registry values, REGDIR and REGDMP to dump the contents of a hive or a key to the screen or a file, and REGFIND to find and replace values in the Registry.
One difficulty with using the resource kit tools to make changes on a large number of machines is that you often must copy the tool to the target machines before running it. Distributing the tools to hundreds (or thousands) of machines and then updating the tools as new versions come out is unwieldy. Making Registry changes without having to keep a utility around for just that purpose makes more sense. You can use REGEDIT to perform command-line Registry adds and changes. The syntax for this command is
regedit (-s) filename.reg
where the -s parameter performs a silent registration, rather than presenting a dialog box that signals a successful registration. New applications commonly use .reg files to register their components during installation. You can use this capability to add and change a machine's Registry. Screen 2 shows an example .reg file. The file header must contain the word REGEDIT4. The example in Screen 2 makes two Registry changes: The first entry changes the path to the Perl binaries in HKEY_LOCAL_MACHINE; the second entry enables the Synchronous Logon feature of user profiles in HKEY_CURRENT_USER. You can use REGEDIT to change or add REG_SZ, REG_DWORD, and REG_BINARY values.
If you've ever wondered what Registry changes occur during the installation of an application, here's a quick little trick you can use to find out. Most applications write changes to the SOFTWARE key in HKEY_LOCAL_MACHINE. Before you install the application, start REGEDT32. Highlight the SOFTWARE key, select Save Subtree As from the Registry menu, and enter a filename to save a copy of that portion of the hive to the file. Next, install your application and then repeat the Save Subtree As process on the SOFTWARE key, entering a new file name. Finally, run the resource kit's WINDIFF utility and open both the before and after file. You'll immediately see the changes. This method also lets you determine Registry changes when you perform a configuration operation.
NT Internals Tools
Occasionally, you find a utility on the Internet or a bulletin board that becomes indispensable in your systems administrator arsenal. I recently found two such utilities, NTFileMon and NTRegMon, at the NT Internals Web site (http://www.ntinternals.com) maintained by Mark Russinovich and Bryce Cogswell.
Each utility uses a process that the authors describe as kernel-mode system call hooking to let you monitor (in realtime) I/O to the file system or to the Registry. The utilities provide a much-needed window into what's really going on when you launch an application or when you hear that hard disk on your NT system spinning without a reason. Screen 3 shows an example of the NTFileMon display when I changed the TCP/IP configuration on an NT workstation. I recently used NTRegMon to help troubleshoot a Microsoft Word problem: With this utility, I discovered that a user's profile (HKEY_CURRENT_USER in the Registry) was configured to grab a document template from a directory that did not exist.
The NT Internals site also includes Windows 95 versions of these two utilities. In addition to NTFileMon and NTRegMon, this site contains other useful, educational utilities for the NT systems administrator. Check out NTSync, which (like UNIX's sync command) forces all data in cache to be written to disk. This action prevents data loss if you have an inadvertent system crash or lose power. NTFSDOS is a well-known utility. This DOS-based device driver can provide read-only access to your NTFS partitions from a DOS boot diskette. NT-Recover lets you use a serial cable to recover files from a crashed NT system's disks. These utilities and other useful information make the NT Internals Web site a must-visit for the NT systems administrator.
Tools for Common Problems
Although this list is by no means complete, the commands and utilities I've discussed in this article represent the most common themes you will likely come across in the day-to-day management of your NT environment. Being a systems administrator in any environment often requires using all the resources at your disposal under stressful situations. I hope this brief list gives you some additional tools and knowledge to make your job easier.
