Many software packages help administrators provide user support without having to visit each user's computer. These packages include Microsoft Systems Management Server (SMS), high-end products such as Computer Associates' Unicenter, and several third-party packages. But if your budget is limited or you are just starting to set up a Help desk, Windows NT has some tools that you can use to remotely diagnose and administer your users' computers. Let us look at some of these tools—most of which are familiar NT diagnostic tools—with an emphasis on their use in remote management.
NT Event Viewer
When you have a problem on your computer, the first place to look is in the NT event logs. You can do the same thing when you have a problem with a remote computer. The process is simple: From the Event Viewer menu, choose Log, Select Computer, then type the computer name or browse for it in the list. You need administrative rights to the client computers to diagnose and fix problems remotely. This requirement means that Help desk personnel must have Domain Administrator or similar rights.
Screen 1, page 160, shows that I am using my computer, GOSHAWK, to view the System event log on another computer, PEREGRINE. Notice that these computers are in different domains. To get the connection I need, I must have a trust relationship set up between the domains, and my domain administrator account in the ROCKYMTN domain must be part of the local administrators group on the client computer. The right column in the System log shows which computer generated a given error, and the title bar at the top of the System log window identifies the log you are viewing.
NT Diagnostics
You can run NT diagnostics on a remote computer, but you will be able to see only a portion of the information you would see if you connected to the computer locally. The reason for this limitation is that you are not really running the diagnostics remotely; what you are doing is looking at the Registry on the remote computer and extracting the necessary information. As Screen 2, page 160, shows, I cannot get some information—such as the video driver version—remotely, although I would see this information if I logged on to PEREGRINE and ran the diagnostics locally.
NT does not have a tab for the memory or drives on the remote computer diagnostics. However, most other pertinent information is available, including data about which services are running, which devices are active, and which interrupts are in use. This information is all useful for troubleshooting.
Performance Monitor
The NT Performance Monitor is one application that most administrators think of when the discussion turns to remote diagnostics. In fact, the manuals for certain products, such as Microsoft SQL Server, suggest that monitoring performance remotely is a good idea. If you want, you can have multiple Performance Monitor windows open at the same time on your screen, each monitoring a different server.
Although the various Performance Monitor counters do not generate much overhead, running Performance Monitor on a server can degrade that server's performance. Performance Monitor runs at priority 12, compared to normal processes that run at priority 8, so Performance Monitor can take away CPU cycles from the very server whose performance you are trying to improve. Therefore, running Performance Monitor remotely from your workstation makes sense.
Performance Monitor's ability to show the data from two or more servers in the same display at the same time is a very useful feature. Screen 3, page 161, shows a file transfer from MERLIN to PEREGRINE. The total bytes per second for the two computers track very closely, as you would expect. But look at the CPU time trace. MERLIN, a 200MHz Pentium MMX system with 128MB of RAM, is running at about 10 percent CPU utilization. PEREGRINE, a 486DX4-100 processor with 32MB of RAM, is not a leading-edge, fast computer (although its name would imply otherwise). Even this simple file transfer takes about 90 percent of its CPU resources. (Time to upgrade to a new, faster PEREGRINE, I think.)
As with the other diagnostic tools, you must have administrative rights to connect to the remote computer. If you attempt to connect to another computer without these rights, you will see the message Computer name not found rather than a more explicit message about rights.
The Registry Editor
NT computer problems often relate to a Registry setting, and you can fix these problems by adding or changing Registry entries. The ability to connect to a remote computer's Registry is invaluable to the administrator. Using regedt32, you can connect to another computer with the menu option Registry, Select Computer. You will see only the HKEY_LOCAL_MACHINE and HKEY_USERS subtrees, but 90 percent or more of all problems you might address with Registry edits are in the HKEY_LOCAL_MACHINE subtree. You can also use regedit, as Screen 4 shows. In this case, you will see two additional subtrees: HKEY_CLASSES_ROOT, which you will never modify directly, and HKEY_CURRENT_USER, which you might occasionally need to modify.
For remote Registry editing, I prefer regedit to regedt32 because of regedit's superior searching capability. Keep in mind that the Registry has security settings that you can change with regedt32; however, you need to keep these settings in place to prevent unauthorized changes.
Server Manager
Server Manager is useful for both remote diagnostics and remote administration. For example, you can connect to another computer and see who is connected, what shares are available, and which shares are in use—the same information you can find in Server Manager for your own computer. You can also define alerts on the remote system, a remote administration feature that saves you time and effort. You can connect to a remote computer and configure it to send NT administrative alerts to your computer when a problem occurs, as Screen 5 shows. Receiving alerts is better than waiting for the phone to ring, with someone else reporting the problem to you.
You can also configure replication (e.g., from a PDC to the BDCs) without leaving your office. Just connect to the PDC using Server Manager and set up replication, then do the same for the BDCs. You can even start the Directory Replicator service on each machine. Select the computer in the list that Server Manager shows, then click Computer, Services from the menu bar. Configure the Startup parameters for the replicator account, and start the service.
Remote Control of Domain Controllers and Servers
So far, I have been talking about running diagnostics on the remote computer. But remote administration has another side. If you load the appropriate tools, you can administer many NT services remotely—
often from an NT workstation or sometimes from a Windows 9x computer. For example, the NT Server installation CD-ROM contains a directory named \clients\srvtools\winnt. Within that directory are directories for the i386 and Alpha platforms. These directories contain tools for administering the NT Server-based services, including User Manager, Policy Editor, RAS, DHCP, and WINS. To install these tools on your NT workstation, run the setup.bat file in the \clients\srvtools\winnt directory and create shortcuts to the various tools. For some reason, the install routine does not build the shortcuts for you. Even stranger, another similar directory with a collection of tools for Win95 computers has a setup routine, but the routine works from only the dialog box at the Add/
Remove Programs applet in Control Panel. However, this routine does add the program folder and shortcuts. These tools even come with Help files in case your Help desk staff needs to look up an option or a command.
User Manager for Domains
If you load the administrative tools onto your workstation, you can administer users, groups, passwords, and account policies as if you were at the domain controller. Remember that all the changes you make to domain accounts take place at the PDC, so the PDC must be up and running (if it is not, you probably have more urgent demands on your time than adding new users).
You need to make changes to domainwide accounts only once. But what if, for example, you must put a global group into a local group on a member server or workstation? Simply open User Manager for Domains, then choose User, Select Domain from the menu bar. When the dialog box pops up, all you will see is a list of domains. This list implies that you can connect only to a domain. To connect to a member server or workstation, type a double backslash (\\) followed by the name of the computer:
\\osprey
Press Enter, and you will be connected to the local accounts database on that computer. You will see only the local users and local groups. By double-clicking a local group, you can modify its membership and add domain global groups to grant your domain users access to local resources.
Remote Control of Server-Based Applications
You will often find that remote control of applications and services is not only more convenient but also more efficient than local control. This efficiency lessens the load on the server.
You can remotely administer many software applications. For example, you can administer SQL Server from an NT workstation (or even a Win9x computer) by installing Enterprise Manager from the SQL Server installation CD-ROM. You can register and administer multiple SQL Server computers centrally from one workstation. The same is true of an SMS site. By installing the SMS Administrator tools on your workstation, you can administer the SMS system, create and monitor jobs, and run queries against the SMS database (which is a SQL Server database and might be on a server other than the SMS system). The fact that these applications run as services on NT makes them easy to start, pause, and stop remotely.
A Simpler Way
Although applications such as SMS offer more features than NT's integral tools, specialized applications also require a substantial investment in time and resources. You can often achieve a high level of remote administration and troubleshooting with just the tools that come with NT.
