Remote Management and Diagnostics
[pic]®
[pic]Windows NT®
Operating System
Windows NT 4.0 Remote Troubleshooting and Diagnostics
White Paper
Abstract
Remote management and diagnostics allow a systems administrator to maintain a network of computers from a remote location and to isolate and resolve system problems as they occur—without having to visit the individual desktop. In today’s widely distributed networks, remote management capability is key to efficient systems management and is crucial in any effort to reduce the total cost of ownership.
Microsoft understands that end-to-end systems management is a huge topic. This white paper does not attempt to cover all aspects of management, but instead describes the remote troubleshooting and diagnostics capabilities of Microsoft® Windows NT® Server and Windows NT Workstation. This paper discusses tools included in Windows NT 4.0, the Windows NT Resource Kits, and various Microsoft add-on packages, including Microsoft Systems Management Server (SMS). Note that this document does not provide extensive procedures for using these tools, but instead describes situations where these tools are used remotely to accomplish specific objectives.
© 1998 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
BackOffice, the BackOffice logo, Microsoft, Windows, and Windows NT are registered trademarks and NetMeeting is a trademark of Microsoft Corporation.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA
0598
Contents
INTRODUCTION 1
Methods of Accessing Systems Remotely 2
Security Considerations and Remote Management 3
Creating Remote Management Accounts 4
Remote Management and Diagnostic Capabilities Included in Windows NT 4.0 5
Remote Management Using WIndows NT Workstation Tools 7
Management Tasks and Tools 7
Diagnostic Tasks and Tools 8
Diagnosing Problems Remotely with Windows NT Workstation 4.0 9
Example: Using the Alerter and Messager Services with Auditing to Identify and Isolate Errors 10
Remote Management Using WIndows NT Server Tools 13
Management Tasks and Tools 13
Diagnostic Tasks and Tools 13
Diagnosing Problems Remotely with Windows NT Server 4.0 14
Example 1: Using Performance Monitor for Proactive Threshold Notification 14
Example 2: Using Server Manager, User Manager for Domains, Printers Folder, and the Registry Editors Remotely for Management and Diagnostic Tasks 17
Remote Management Using Windows NT Server 4.0 Resource Kit Tools 21
Resource Kit Management Tools 21
Resource Kit Diagnostic Tools 23
Solving Problems Remotely Using Windows NT Server 4.0 Resource Kit Tools 26
Example1: Using the Remote Console to Remotely Check the Status of Services and Machine State 27
Example 2: Using Remote.exe and Built-in Debugging Tools to Remotely Debug a System Stop Error 30
Example 3: Using Client-Based Network Tools and Web Management 40
Remote Management Over the Internet 42
Remote Management Tasks and Tools 42
Security 43
Installing and Starting the Software 43
Administering User Accounts with Web Management 44
More Information About Web Management 44
Solving Problems Remotely Using Microsoft Add-On Tools 45
Microsoft NetMeeting 45
NetMeeting Architecture Components 46
Example: Using NetMeeting for Remote Diagnostics 46
Microsoft Systems Management Server 51
Remote Network Troubleshooting with Network Monitor and the Network Monitor Agent 51
Troubleshooting Network Monitor Agent Using the Remote Event Log 56
Systems Management Server Help Desk and Remote Diagnostic Tools 56
Microsoft’s Future Remote Management and Diagnostic Strategy 59
The Microsoft Management Console 59
The Console and the Role of Snap-ins 59
Key Benefits of Using MMC 59
Microsoft Active Directory 60
The User Interface and Management Tools 60
A Single Point of Administration 61
Increased Management Granularity 62
Increased Security Granularity 62
A Unified Directory 63
API Support 63
Summary of Microsoft Active Directory Features and Benefits 64
Microsoft Windows Scripting Host (WSH) 65
Web-based Enterprise Management (WBEM) and Windows Management Instrumentation (WMI) 65
What Does WMI Do? 66
How Does WMI Work with WBEM? 67
Resources and Where to Find Additional Information 68
Resources 68
More Information 70
Appendix A 71
Remote Functionality of Management Tools in Windows NT Workstation 4.0 71
Diagnostic Tools and Services in Windows NT Workstation 4.0 72
Appendix B 74
Remote Functionality of Management Tools in Windows NT Server 4.0 74
Diagnostic Tools and Services Included in Windows NT Server 4.0 74
Introduction
The ability to manage and perform system diagnostics from a central or remote location has become increasingly important to today’s enterprise customers. This interest in remote management arose in part because of the increased size and geographically dispersed nature of today’s computer networks, and also because of the escalating costs associated with maintaining such networks (often referred to as the Total Cost of Ownership, or TCO).
Support for remote management and diagnostics allows enterprise system administrators to more quickly and cost-effectively maintain their systems, without requiring them to visit each individual desktop. The benefits of remote management and diagnostics—faster response to issues, simplified server management, the ability to use off-site technical specialists for problem solving or system repair—result in less downtime and more satisfied computer users.
Microsoft understands that customers need to be able to remotely manage servers and workstations and the software that runs on these computers. The ability to remotely manage and diagnose problems on servers and workstations allows customers to reduce TCO and lower system management workload. System administrators need the ability to define software policies that specify the applications, data, and desktop environment a user can access, and automatically update and synchronize applications, resources, and data on a per-computer or per-user basis.
To meet these needs, Microsoft is committed to building operating systems that include remote management and diagnostics capabilities. Building these features into the operating system will:
• Ensure system robustness
• Increase ease of use
• Improve system availability
• Facilitate systems management from a central location
• Increase product supportability
• Reduce the costs associated with deploying and maintaining computers in the enterprise
Microsoft understands that end-to-end systems management is a huge topic. This paper does not attempt to cover all aspects of management, but instead focuses on the remote troubleshooting and diagnostic capabilities of Windows NT 4.0. Note that the Windows NT remote capabilities described in this document give the system administrator or qualified user the ability to perform certain operations over a network. These operations may be limited to the ability to save and retrieve files, or they may include all features of a particular application or tool. However, in most cases, remote troubleshooting and diagnostic operations offer a subset of the application or tool's full functionality.
Caution: Before performing remote troubleshooting or diagnostic functions on a system that contains sensitive information, please review the subsection, " Security Considerations and Remote Management," in this white paper.
Methods of Accessing Systems Remotely
Windows NT offers powerful built-in networking capabilities, and Microsoft add-ons—such as File and Print Services for NetWare (FPNW) and Distributed File System (Dfs)—extend these capabilities. Third parties also provide many solutions that extend the networking capabilities of Windows NT Server, including a wide variety of options for remote access. However, when you select a method for remotely accessing systems, you should consider the following factors:
• Proximity to the remote system. This is an important consideration because remote diagnostic procedures done on a local area network (LAN) are typically far more responsive than those done over a wide area network (WAN).
• Networking bandwidth requirements of the tools. Command-line tools such as those offered in the Windows NT Resource Kit tend to require far less networking bandwidth than do graphical tools such as Microsoft NetMeeting™ conferencing software, which offers advanced conferencing, application sharing, and collaboration.
• Convenience and flexibility of the network connection method. This becomes an important factor when an administrator or support technician must diagnose a system at a remote location in a prompt manner. Remote Access Service (RAS) is built into Microsoft Windows® for Workgroups 3.11, Windows 95, Windows NT Workstation, and Windows NT Server so administrators can use any of the operating systems to securely access the LAN using Windows NT Server’s native RAS. Secure access can be granted conveniently from anywhere in the world, either through a dedicated leased line-based WAN or more economically over the public Internet using Windows NT Server integrated virtual private networking (VPN) support. Windows NT Server also supports a host of other media for better performance, including Integrated Services Digital Network (ISDN), a digital architecture that provides information transport using the public telephone network, and the Multilink Protocol (MP), which combines multiple physical links into a logical bundle to increase bandwidth.
• Security requirements. If you are considering using the Internet as a connection method, solutions such as Microsoft’s point-to-point tunneling protocol (PPTP) provide a VPN tunneling solution that minimizes the risk of unauthorized monitoring of network packets. Most network connection methods also offer encryption during the authentication phase to prevent unauthorized monitoring of networking packets.
• Cost of the network connection method. Does the connection method offer enough bandwidth to make it a cost-effective solution?
• Reliability of the network connection method. This is a very important factor to consider because it is critical that the network connection method be reliable. Nothing is more frustrating than having an unreliable network connection when trying to diagnose why your server has just gone down. Consider that analog dial-up connections are typically far less reliable than dedicated networking connections, such as T1, or packet switched connection methods, such as X.25 and asynchronous transfer mode (ATM).
• Anticipated frequency of use. How often do you perform administrative and diagnostic tasks remotely outside of your local area network? You should balance this factor against the other factors mentioned above, such as cost of the connection method. If you perform these operations infrequently, you may not need high bandwidth and expensive connection alternatives such as T1 or ATM. For example, a system administrator working from home frequently may find that dial-up connections are too slow and unreliable but that ISDN or X.25 provide an acceptable solution to his or her communication needs.
These are just some of the factors to consider when determining the best method to use for accessing your systems remotely.
The following table shows some advantages and disadvantages of several popular network connectivity methods that are used in WANs today.
|Method |Advantages |Disadvantages |
|Dial-up connection through RAS |Easy to configure; widely available|Limited performance; can be |
| |because it uses existing telephone |susceptible to line noise. |
| |lines; very inexpensive. | |
|ISDN |Fairly inexpensive; higher |Not as widely available as dial-up |
| |bandwidth than dial-up connection; |connections; requires special |
| |improved reliability. |hookup from the carrier. |
|T-Carrier (T1) |Reliable; higher bandwidth than |Expensive; requires special |
| |most other WAN connection methods; |equipment and hookup from the |
| |scales up based on bandwidth needs;|carrier. |
| |full duplex. | |
|X.25 |Reliable. |Expensive. |
Security Considerations and Remote Management
By default, Windows NT Workstation and Windows NT Server 4.0 disable the Guest account to prevent unauthorized network access to users who do not have a domain or local user account on the system. Therefore, creating a user account for remote access is a required preliminary step in ensuring that diagnostic and administrative tools function properly in remote mode. User accounts for remote access can be new user accounts or existing accounts. These accounts can be local to the particular computer or they can be created in the domain in which the system belongs. When establishing user accounts for remote access and when choosing remote management tools, you should consider the tasks that you will be performing and the sensitivity of the data stored on your system.
For example, many diagnostic tools (such as Registry Editor, Windows NT Diagnostics, Event Viewer, and Performance Monitor) require administrative access on the remote system to function properly or they will generate errors. Some diagnostic tools, such as Remote.exe from the Windows NT Resource Kit and Microsoft NetMeeting 2.1 conferencing software, provide limited security. Administrators should take this into consideration when providing remote access to systems with sensitive data. Conversely, administration tools such as User Manager and the Printers folder may require only a user account with user rights or a subset of administrative authority to provide some functionality.
Security is a necessary concern for remote management. Security itself is a function of the software product and the company policy. As the need for remote tools increases, so does the need for security. Remote tools planned for future versions of Windows NT—for example, Microsoft Management Console, Web-based Enterprise Management (WBEM), Directory Services (DS), and “snap-ins”—are being built with security in mind.
The next subsection provides some guidelines for setting up and using remote management accounts without compromising system security.
Creating Remote Management Accounts
There are several methods you can use to create an account with the proper access rights for remote access, and each method has advantages and disadvantages. (For specific procedures, refer to your Windows NT product and Resource Kit documentation.) To reduce security risks, many corporate system administrators may not want to provide full administrative access to anyone but themselves. Keep in mind, however, that you will need to create a user account or use an existing account to provide the necessary security and access required by the remote tools you will be using.
Although there are no hard and fast rules for creating an administrative user account for remote systems management (diagnostics and maintenance), you should keep the following suggestions in mind:
• You may want to use a “hard” password on the user account for remote access, and you may want to change the password frequently. Hard passwords contain uppercase and lowercase letters, numeric characters, and special characters such as punctuation.
• If you are providing remote diagnostic access to people outside of your company or immediate group, turn on auditing to log all activity. In addition, you should physically monitor all activity while the system is being accessed remotely. Never leave the system unattended.
• If you have created a user account specifically to allow people outside your company or immediate group to remotely diagnose your system, you may want to disable the account when it is not being used. You can then choose when and whether to enable the account, without the concern that unauthorized access will take place.
• Many administrators rename the default administrator’s account on all servers. Renaming this account helps to prevent unauthorized access by hackers who may be attempting to break into the network using the default administrator’s account.
• If you are planning to use Remote Access Service (RAS) to dial in to the server for remote management or diagnostics, you will need to grant dial-in permission to the user account ahead of time.
• If you are using a user account that is not a member of the remote system's domain or local user accounts and the guest account is disabled, you will need to establish a session with the remote system. If you do not do this first, access will be denied in many of the tools. An easy way to establish a session with the remote system is to connect to the IPC$ share of the remote system using an account and password that exists in the remote system’s domain or local user accounts.
• In some cases, it is possible to create a new account group and add the necessary user rights to this new account group so that remote management and diagnostic tools work properly without needing an administrative user account. This account group offers tighter security granularity and the flexibility to add additional user accounts to this group, while still allowing tools to function remotely. See the product documentation for additional details on how to do this. If you choose to create an account with limited administrative authority, be sure to test the management and diagnostics tools to ensure proper operation.
• For the purposes of remote diagnostics, access to system files and data is frequently needed, but access to user files and data is not usually necessary. You may want to tightly restrict access to sensitive data and user files. If you are using the FAT file system, consider using the NTFS file system. NTFS offers discretionary security features that allow administrators to lock down individual file and directory access for users or groups of users.
• Be aware that there is limited security with SNMP alert messages. Data in these messages may be sent in plain text; exercise caution when sending these messages over unsecured links. See RFC 2272 for additional information. (RFC 2272 can be found at .)
Remote Management and Diagnostic Capabilities Included in Windows NT 4.0
Microsoft includes remote capability in many of the management and diagnostic tools for Windows NT Workstation and Windows NT Server. This capability allows system administrators to accomplish server and workstation management tasks from a central location and to diagnose and troubleshoot problems from a remote site. These remote-capable tools can be broken into three separate areas:
• Management tools, the majority of which use a graphical user interface (GUI)
• Services
• Diagnostic information-gathering tools, the majority of which use a command-line interface
The remainder of this paper examines some of the remote management and diagnostic tasks that administrators can accomplish using tools that are provided in Windows NT Workstation, Windows NT Server, the Windows NT Server Resource Kit, and in various add-on packages including Systems Management Server (SMS). Each section provides a summary of remote management and diagnostic tasks and the tools that can be used to complete these tasks. Then, the sections describe situations where these tools were used remotely to diagnose and resolve system problems. Finally, the paper describes planned enhancements to remote management that will be included in future versions of the Windows NT operating system.
Remote Management Using WIndows NT Workstation Tools
Management Tasks and Tools
The following table lists management tasks that can be performed remotely using tools included with Windows NT Workstation 4.0.
|Remote Management Task |Tool to Use |
|Add and modify user accounts. |Command prompt net user command |
|Add and modify user groups. |Command prompt net group command |
|Add, display, or modify local groups. |Command prompt net localgroup command |
|Send text between two or more computers. |Chat |
| |Command prompt net send command |
|Connect and disconnect from remote shared resources |Windows NT Explorer |
|such as file shares and printers. |My Computer |
| |Command prompt net use command |
|Copy, delete, move, create, modify, open files and |Windows NT Explorer |
|folders, and run programs. |Internet Explorer |
| |My Computer |
| |Find command |
| |Command prompt copy, xcopy, delete, move, and more |
|Run programs, access computers and shared resources,|Run command |
|open files and folders remotely, by using Uniform |Command prompt |
|Naming Convention (UNC) network commands. |Internet Explorer |
|Find computers, files, folders, text strings, and |Find command. |
|more, using a variety of search criteria. |Windows NT Explorer |
| |Network Neighborhood |
|Add shares and assign security, auditing, and |Printers folder |
|ownership to a printer. Configure printer- specific | |
|settings, such as ports, spooling, security, | |
|scheduling, sharing, device, print processor, | |
|separator page, driver, and description settings. | |
|Configure document settings such as paper size and | |
|orientation. | |
|Set the computer's internal clock from a remote |Command prompt net time command |
|source. | |
|Send administrative alerts. |Command prompt net send command |
|View printer and print job queue status information.|Printers folder |
| |Command prompt net print command |
| |Command prompt LPQ tool |
|Update the user account database, and modify |Command prompt net accounts command |
|password and logon requirements for all accounts. | |
|View and browse shared resources on a remote |Network Neighborhood |
|computer. |Command prompt net view command |
| |Find command |
| |Run command |
| |Internet Explorer |
| |Windows NT Explorer |
| |My Computer |
Diagnostic Tasks and Tools
The following table lists diagnostic tasks that can be performed remotely using tools included with Windows NT Workstation 4.0.
|Remote Diagnostic Task |Tool to Use |
|Configure TCP/IP client printing options, and view |Line Printer Remote (Lpr.exe) |
|print queue information on host and PC host |Line Printer Queue (Lpq.exe) |
|systems. | |
|Copy files to UNIX-based and PC host systems. |Remote Copy Protocol (Rcp.exe) |
| |File Transfer Protocol (Ftp.exe) |
| |Trivial File Transfer Protocol (Tftp.exe) |
|Debug kernel-mode services, drivers, and processes.|I386kd.exe using Remote.exe from the Windows NT |
| |Resource Kits (this is included in both the Server and |
| |Workstation versions) |
|Debug user-mode applications, services, and |Cdb.exe using Remote.exe from the Windows NT Resource |
|processes. |Kit |
| |API Profiler (Apimon.exe) |
|Display IPX routing information such as the server |IPX Route (Ipxroute.exe) |
|SAP table. | |
|Find text strings in files and folders and match |Find String (Findstr.exe) |
|against patterns. This tool allows you to test for | |
|certain trigger conditions in remote files and can | |
|be very useful in batch files. | |
|Gather information about network connectivity and |TCP Ping utility (Ping.exe) |
|systems that are active on the network. |Net view, session, and statistics commands |
| |Network Statistics (Netstat.exe) |
|Monitor performance of system objects in real time.|Performance Monitor (Perfmon.exe) |
|Log to a file, send administrative alerts on | |
|thresholds, and generate reports. | |
|Replicate files automatically (import mode) to your|Directory replication service |
|computer from a remote computer. | |
|Run a process on a remote host. Run commands on a |Remote Execute (Rexec.exe) |
|remote host system without logging on. |Remote Shell (Rsh.exe) |
|Search, add, delete, edit, view, set security, |Registry Editor (Regedit.exe) |
|print, import, and export registry information. |Registry Editor (Regedit32.exe) |
|Send administrative alerts to other computers or |Alerter service |
|users on the network in the case of a catastrophic |Performance Monitor (Perfmon.exe) |
|error. |SNMP agent |
| |Net send command |
|Test and diagnose NetBIOS over TCP name resolution |NetBIOS Statistics (Nbtstat.exe) |
|problems. Identify NetBIOS name conflicts on the | |
|network. | |
|Test and diagnose TCP/IP host name resolution (DNS)|Name Service Lookup (Nslookup.exe) |
|problems. | |
|Test for remote systems to be active on the |TCP Ping utility (Ping.exe) |
|network. |Net view command |
| |Network Statistics (Netstat.exe) |
|Test modem connectivity and negotiation. |HyperTerminal (Hypertrm.exe) |
| |Dial-up Networking (Rasphone.exe) |
|Trace TCP/IP routing hop counts to a target on the |Trace Route (Tracert.exe) |
|network. | |
|View and control print spooler configuration and |Net print command |
|status. Remove stuck print jobs, purge the printer. |Printers folder |
|The Printers folder also allows you to add new | |
|printers and change all printer and document | |
|properties. | |
|View and print system and hardware information. |Windows NT Diagnostics (Winmsd.exe) |
| |Registry Editors (Regedit.exe, Regedt32.exe) |
|View system, application, and security events and |Event Viewer (Eventvwr.exe) |
|error messages. |Performance Monitor (Perfmon.exe) |
Diagnosing Problems Remotely with Windows NT Workstation 4.0
This subsection provides an example of Windows NT Workstation tools used to remotely diagnose problems on Windows NT Server. In the situation described, Windows NT Workstation acts as the client. The administrator uses the client computer to connect remotely to a computer running Windows NT Server, and then diagnoses and resolves the server problem.
Example: Using the Alerter and Messager Services with Auditing to Identify and Isolate Errors
In this example, the system administrator needs to work on a server at a branch office that is many hundreds of miles away from corporate headquarters. While away, he wants to be notified of any potential catastrophic problems on the server. Before he leaves, he turns on the Messenger service on both his portable computer and server. Using Control Panel, he configures the Server tool on the server at the corporate headquarters to send administrative alerts to the server on which he is working. In addition, he configures the Alerter service to send administrative alerts to his user account in case he is sitting at some other system.
Late in the day, he receives an administrative alert pop-up message on his portable computer where he is logged on, notifying him that a problem has occurred. Fortunately, he has configured the Alerter service to send alerts to his user account name instead of just a computer name, or he may have missed this alert.
[pic]
Figure 1. Messenger Service Alert Sent to Administrator’s User Account
This is a serious problem. Back at corporate headquarters, the server called “Newpenny” has just displayed a STOP screen error message and restarted. The pop-up message provides information about what happened, but doesn’t provide any background or causal information. The administrator is concerned that the circumstances that caused the problem may occur again. How can he isolate the source of the problem, determine what went wrong, and prevent it from recurring when he is hundreds of miles away?
The administrator can diagnose and resolve the problem if he can gather enough information about what led up to it. Fortunately, the administrator had previously used the Control Panel System Properties dialog to enable the Recovery options, Write an event to the system log and Automatically reboot (found in the Startup/Shutdown tab, as shown in Figure 2).
[pic]
Figure 2. Setting the Recovery Options in the Control Panel System Properties
He also had turned on auditing in User Manager, and had selected Success and Failure of several items as audited events. In this case, the Process Tracking and Restart, Shutdown, and System events are important in solving this mystery.
Our administrator knows the date and time that the stop error occurred and decides to remotely attach to the server now that it is back up and running to see if he can pinpoint more information from the event logs. Because his branch office has a T1 network connection to corporate headquarters, he can remotely diagnose the problem with the tools he has on his portable computer, which is running Windows NT Workstation 4.0. He uses his existing domain user account and starts Event Viewer on his portable computer. He then selects the Select Computer option from the Log menu, and types Newpenny. After a brief delay he is looking at the logs on the Newpenny server. He first looks at the System log to see if any services or devices could have failed and caused the server to stop. Although he finds a few informational events, everything seems to have been operating normally during the period leading up to the problem. The Application log is not helpful; there is limited information to indicate why the problem occurred. The Security log, however, proves to be very useful in identifying the source of the problem. Looking at the events just prior to the STOP error occurring, the administrator finds through the process audit that a user ran an application named Crash.exe.
This event was logged very close to the time that the Newpenny server suffered the STOP error. Figure 3 illustrates what this would look like in the Event Viewer Security Log.
[pic]
Figure 3. Security Log Showing Crash.exe Process
The administrator looks at some of the events that were recorded after this event and finds that the server restarted almost immediately after the Crash.exe application ran. He decides to contact his IS staff at corporate headquarters and, after investigating what took place in the server room, finds the cause of the problem: A staff member needed to test an application his company was developing to test hardware, and inadvertently ran that application on the Newpenny production server instead of the test server. The administrator takes steps to ensure that this does not happen again.
Remote Management Using WIndows NT Server Tools
Management Tasks and Tools
The following table lists management tasks that can be performed remotely using tools included with Windows NT Server 4.0. (Windows NT Server includes all of the management tools included with Windows NT Workstation with additions and changes as noted in the table.)
|Remote Management Tasks |Tool to Use |Type |
|Administer DHCP servers. Add and delete DHCP servers; |DHCP Manager (Dhcpadm.exe) |GUI |
|configure remote DHCP client workstations. Add, activate, | | |
|reserve, and delete client IP addresses. | | |
|Import and export files and directories to and from remote |Directory Replication |Service |
|Windows NT-based systems. |(Lmrepl.exe) | |
|Administer DNS servers, view DNS server information, and add |DNS Manager (Dnsadmin.exe) |GUI |
|DNS resource records. | | |
|Configure the location where license information is |License Manager (Llsmgr.exe) |GUI |
|replicated, including the ability to send all licensing | | |
|information to a single “enterprise” server. | | |
|Permits administrators to establish system policies to enforce|System Policy Editor |GUI |
|policy rules for all computers in a domain or for individual |(Poledit.exe) | |
|computers. Profile restrictions can be set on individual users| | |
|or groups. Policy editor can remotely edit certain registry | | |
|settings on both system and user settings. | | |
|Manage domain user accounts and policies. Connect to remote |User Manager for Domains |GUI |
|domains, add, delete, and edit users and groups. Configure |(Usrmgr.exe) | |
|user-specific logon information such as logon properties. | | |
|Administer Windows Internet Name Service (WINS) servers. Add |WINS Manager |GUI |
|and delete servers; change and view server and replication |(Winsadmin.exe) | |
|partner configuration. View summary and detailed status | | |
|information on the WINS database. Show database records; | | |
|initiate database scavenging; add, edit, delete, and import | | |
|static mappings. | | |
Diagnostic Tasks and Tools
The following table lists diagnostic tasks that can be performed remotely using tools included with Windows NT Server 4.0. (Windows NT Server includes all of the diagnostic tools included with Windows NT Workstation with additions and changes as noted in the table.)
|Remote Diagnostic Task |Tool to Use |
|Sniff networking packets and analyze them from a remote |Network Monitor (Netmon.exe) |
|network. Monitor network activity proactively. | |
|View a series of log files on a remote system. |Log viewer (Logview.exe) |
|Modify certain registry keys for system or user settings on |Policy Editor (Poledit.exe) |
|one or several computers easily. | |
Diagnosing Problems Remotely with Windows NT Server 4.0
This subsection provides examples of Windows NT Server tools used to remotely diagnose problems on Windows NT Servers and Workstations.
Example 1: Using Performance Monitor for Proactive Threshold Notification
System administrators can use the Performance Monitor tool included in Windows NT Workstation 4.0 and Windows NT Server 4.0 to send administrative alerts over the network, record events to the event application log, and launch an optional program or batch file when high and low thresholds are reached. This tool can be extremely useful to administrators who need to be notified remotely when a resource has reached a certain threshold and administrative action is necessary. Even if the administrator is not physically near the system, he or she can still be notified of a pending maintenance need on the server before anything serious occurs.
For example, it is not practical for an administrator to wait physically at a server, monitoring it until it is time to add additional hard drives to increase capacity. On the other hand, an administrator doesn’t want to be notified after the system has completely run out of disk space and the integrity of the system has been compromised. It would be ideal if the administrator could be notified through a pager, e-mail message, network alert, or other effective communication mechanism when the available disk space on a partition had dropped to a certain percentage of the total disk space. This would give the administrator sufficient time to delete unneeded files, archive files, or add disk space during the next scheduled maintenance period.
In this example, our administrator has chosen to use the alert capability of Performance Monitor to accomplish this task. She can switch to alert mode in Performance Monitor by clicking Alert on the View menu.
As Figure 4 illustrates, our administrator has chosen to remotely monitor the percentage of free disk available on both logical disks for the server called ”Jade.”
[pic]
Figure 4. Threshold Alert for Computer Called “JADE”
She has configured Performance Monitor to run the Pageme.bat file, which is located in the Batch folder on drive C. This file runs a program that sends a page to the administrator's personal pager. In addition, the administrator has set a low threshold so that the system will only run the batch file and alert her if the percentage of disk space on either logical drive C or logical drive D falls below 15 percent of the total usable space on the logical disk.
Also note that she has chosen to run the batch file every time this low threshold is reached, so that she will receive repeated pages if the problem persists. This batch file can be modified to take proactive steps to solve this particular problem, such as removing temporary files that are known not to be needed or archiving and deleting large files that may be old.
Note that the Alert Options dialog box (click Alert on the Options menu) allows the administrator to take other actions and to change the update frequency if necessary. The default Periodic Update is 5 seconds; however, in this example, our administrator has changed it to 60-second intervals (see Figure 5).
[pic]
Figure 5. Alert Options with Update Time Set for 60-second Intervals
The uses for Performance Monitor in this type of a proactive diagnosis are virtually endless. Consider just a few examples of some other types of proactive remote diagnostics you can accomplish with Performance Monitor:
• By monitoring to see if the thread count of a process drops below 1, you can determine if an application has stopped. If you are using Performance Monitor locally, you can then launch a batch file to restart the application. This can be useful for mission-critical applications that cannot be down for any length of time.
• By monitoring memory counters such as Page Read/sec, and Available Bytes, you can be alerted if your server is reaching a point where more physical memory is needed.
• By monitoring processor counters such as %Processor Time and Processor Queue Length, you can be alerted if a CPU bottleneck is occurring, or a process has stopped responding or is deadlocked.
• By monitoring system counters such as System Uptime, you can be notified if a server unexpectedly stops functioning.
• By monitoring server counters such as Error Access Permissions, Errors Granted Access, and Errors Logon, you can determine if someone is trying to hack into your system or open files that he or she does not have permission to access. You can use Event Viewer to audit and view these Security events remotely.
You can find further information on performance monitoring in the Windows NT Server and Workstation Resource Kits. These kits include several chapters devoted to performance monitoring tools and to detecting bottlenecks.
Example 2: Using Server Manager, User Manager for Domains, Printers Folder, and the Registry Editors Remotely for Management and Diagnostic Tasks
This example demonstrates how the management and diagnostic tools included with Windows NT Server 4.0 can be used to perform some fairly common remote management tasks.
In many companies, departmental administrators are responsible for administering servers that run Windows NT. In some cases, these responsibilities are handled collectively by a group of administrators in the Information Technology (IT) department. The IT approach provides administrative flexibility and also may allow the IT department to delegate management duties or to spread responsibility among several administrators.
For example, domain management could be configured using trusts in a master domain structure that allows user accounts to be managed at the departmental level, whereas resources are all kept in centralized domains based on their resource type. This approach works well in a company that has many servers that are grouped together and assigned to do one specific task, such as file and print services. In these cases, there is usually not one single administrator who is responsible for all management. These teams of administrators can be assigned to manage key server resources such as File and Print, or Database and Storage services on servers running Windows NT. This form of administrative grouping helps to ensure that one administrator isn’t overworked and adds some redundancy in the event that an administrator is unavailable. In the department account domains, one administrator can be responsible for all account management for his or her department, especially if the management workload is light.
In our example, the Human Resources (HR) departmental administrator is unavailable for some length of time due to an illness. This company has recently hired a new vice president of HR, and the internal computer department has configured a new computer system with Windows NT Workstation 4.0 and has installed it on his desktop. Normally, the internal computer department would contact the departmental administrator to create and configure a user and computer account with the appropriate permissions on the resources that the new employee would need. In this case, however, because of the administrator’s absence, the accounts were not created and the permissions were never set. The HR vice president now starts up his computer and receives an access denied message whenever he attempts to connect to any HR resources on the network.
The company's internal help desk identifies the problem quickly by starting the Windows NT Diagnostics tool, connecting to the vice president's computer remotely, and then selecting the Network tab. The help desk technician determines that the vice president's system is not a member of the domain to which it should belong. The vice president of HR has been logging on with a local user account that restricts his ability to see resources in other domains.
The resource administrator is faced with the following management tasks that must be done remotely:
• Create a user account and assign it to the proper groups.
• Create a machine account.
• Create, assign shares, and set permissions on resources.
• Add a printer and configure the settings.
• Change some specific registry settings.
Note that because she is not an administrator of the remote domain, the resource administrator will be denied access if she does not first establish a session to the remote domain using an administrative account from that domain. She must first obtain this information from the departmental administrator or someone in the department who can create an administrative account for her.
Then, using the tools included with Windows NT Server 4.0, she performs the procedures described next.
Creating the User Account and Assigning It to the Appropriate Groups
1. The administrator connects to the remote domain’s primary domain controller (PDC) interprocess communication share (IPC$) by using the command
net use \\computername\IPC$ /User:accountname password
Note that she can enter this command from a command prompt or from the Run dialog box, in which case she can omit the net use command.
The IPC$ share creates a connection between two network computers so that applications running on the two computers can exchange information directly, without having to write to or read from the file system.
2. She starts the User Manager tool from the Administrative Tools group on her local server.
3. Using the Select Domain option on the User menu, she connects to the remote domain, and then creates the user account, assigns it to the appropriate groups, and sets the account policies.
Creating the Machine Account in the Remote Domain
1. The administrator starts the Server Manager tool from the Administrators group on her local server.
2. Using the Select Domain option on the Computer menu, she connects to the remote domain.
3. She adds a new workstation computer account to the domain. At this point, the vice president's workstation will be able to log on to the domain and see networking resources.
Creating, Assigning Shares, and Setting Permissions on Resources
1. The administrator notices that the vice president will need access to sensitive data on one of the resource servers. She starts the Server Manager tool and selects the correct server.
2. Using the Shared Directories option from the Computer menu, she remotely creates a share on this server, and restricts the permissions so that only the vice president has access to the share’s data.
3. While creating the shared directory, the administrator uses the Services option on the Computer menu to check the services running on the remote server. She notices that one of the services is not started, and the startup type is not set correctly. She corrects this by starting the service and changing the startup type so that when the server is restarted, the service will start automatically.
Creating a printer remotely and Configuring the Settings
1. Once again, the administrator connects to the remote domain’s primary domain controller (PDC) interprocess communication share (IPC$) by using the command
net use \\computername\IPC$ /User:accountname password
2. She then remotely creates the printer by using one of several methods:
• From the Run dialog, she types \\computername, and then selects the Printers folder.
• She uses the Find Computer feature as shown in Figure 6. After finding the remote computer, she can double-click the computer name to open it, and then click the Printers folder.
[pic]
Figure 6. Adding a Printer Remotely
3. Finally, she starts the Add Printer wizard to install a printer and driver on the remote system.
Note: The Windows NT 4.0 Printers folder allows you to complete all functions remotely except installation of new port monitors, which must be done locally. This means that you must install port monitors (such as HPMON used for HP Jetdirect attached print devices) locally. Thereafter, you can create and manage printers remotely. The Printers folder also permits you to troubleshoot and diagnose printer problems remotely, including such tasks as removing print jobs that are stopped, purging a printer, configuring a printer’s device and document properties, and so forth.
Changing Registry Settings
The administrator must complete a few modifications to the registry on the vice president's system to finish the process. The registry editors included in Windows NT 4.0 allow the administrator to gather information, change the configuration and behavior of the system and processes, and perform diagnostic tasks both locally and remotely. However, an administrator should never modify the registry without considering the security implications and without planning for system recovery. Registry security access should not be left open-ended and, unless steps are taken to save the registry keys before they are changed, it may be difficult or impossible to restore the configuration if the system fails after the change.
The administrator must have the appropriate administrative rights to connect to the server and modify the registry settings remotely. The default configuration for Windows NT Server 4.0 permits only administrators of that system to remotely access the registry.
1. To connect to the remote system and modify the registry, the administrator starts Regedt32.
2. She clicks the Select Computer option on the Registry menu, and then types in the name of the computer.
3. She edits the registry, and then disconnects from the remote system.
The vice president’s system is now fully configured.
These examples illustrate just a few of the remote management and diagnostic tasks that you can do with the GUI-based tools provided in Windows NT Server. Note that some of these same management tasks can be done in the local domain using the command line and tools included with Windows NT, such as Net.exe.
Remote Management Using Windows NT Server 4.0 Resource Kit Tools
Resource Kit Management Tools
The following table lists management tools that are included in the Windows NT Server 4.0 Resource Kit. (Note that some Windows NT Resource Kit tools described in this section are considered to have remote functionality because they contain features that let them operate over networked drives. )
|Tool Name |Remote Management Functionality |Type |
|Addusers.exe |32-bit batch-driven tool that uses a comma-delimited file to |CMD |
| |create, write, and delete user accounts. | |
|Auditpol.exe |Enables the user to modify the audit policy of the local |CMD |
| |computer or of any remote computer. | |
|Dhcpcmd.exe |DCHP command-line management tool. |CMD |
|Diskuse.exe |Scans directories on a hard disk and reports on space used by | |
| |each user. | |
|Dnscmd.exe |Manages and obtains statistics from local and remote DNS |CMD |
| |servers. | |
|Findgrp.exe |Finds all direct and indirect group memberships for a specified|CMD |
| |user in a domain. | |
|Floplock.exe |Locks floppy disk drives. |Service |
|Getsid.exe |Compares the user security IDs (SIDs) of two accounts. |CMD |
|Global.exe |Displays members of global groups on remote servers or domains.|CMD |
|Grpcpy.exe |Copies the user names of an existing group to another group in |CMD |
| |the same or another domain. | |
|Netdom.exe |Manages domains from the command prompt. |CMD |
|Nltest.exe |Performs many network administrative tasks from the command |CMD |
| |line. | |
|Ntrights.exe |Grants or revokes Windows NT privileges to or from a user or |CMD |
| |group of users. | |
|Permcopy.exe |Copies share-level permissions (access control lists [ACLs]) |CMD |
| |from one share to another. | |
|Perms.exe |Displays users' access permissions for a specified file or set |CMD |
| |of files. | |
|Ralist.exe |Displays RAS server announcements from a network. |CMD |
|RAS Manager by Virtual |Enables network administrators to manage Remote Access Service |GUI |
|Motion |(RAS) separately for each user, RAS server, or port. | |
|Rasusers.exe |Lists all user accounts that have been granted permission to |CMD |
| |dial in to the network through Remote Access Service (RAS). | |
|Rmtshare.exe |Command-line utility that allows you to set up or delete shares|CMD |
| |remotely. | |
|Rshsvc.exe |TCP/IP remote shell service that provides a command-line shell |Service |
| |or single command execution service for remote users. | |
|Rshxmenu.exe |Shell extension that makes editing security objects easy by |GUI |
| |adding a security menu to the Explorer context menu for files. | |
|Sc.exe |Configures, retrieves, and communicates Service Control Manager|CMD |
| |(SCM) information from the command prompt. | |
|Secadd.exe |Command-line utility that enables you to add user permissions |CMD |
| |to a registry key. | |
|Secedit.exe |Security context editor. |GUI |
|Shareui.dll |Shell extension to Windows NT Explorer that makes it easier to |GUI |
| |manage network shares. | |
|Shutdown.exe |Remote server shutdown. |CMD |
|Shutgui.exe |Remotely shut down or restart a computer running Windows NT. |GUI |
|Soon.exe |Schedules commands and programs on either the local or a remote|CMD |
| |computer, by generating and executing an appropriate AT | |
| |command. | |
|Subinacl.exe |Obtains security information on files, registry keys, and |CMD |
| |services, and transfer this information from user to user, from| |
| |local or global group to group, and from domain to domain. | |
|Telnetd.exe and Rsm.exe|Telnet Server Beta provides a solution for running command-line|CMD, Service |
| |utilities, scripts, and batch files from clients on a network. | |
| |This tool works independently of the client's operating system.| |
|Web Management |Allows limited remote management of Windows NT Server through |GUI |
| |Internet browsers (including Internet Explorer 2.0 and later) | |
| |from Windows, Macintosh, and UNIX platforms. | |
|Winscl.exe |WINSCL is a command-line management and diagnostics tool for |CMD |
| |managing WINS. | |
Resource Kit Diagnostic Tools
The following table lists diagnostic tools that are included in the Windows NT Server 4.0 Resource Kit.
|Tool Name |Remote Diagnostic Functionality |Type |
|Atanlyzr.exe |Performs an AppleTalk lookup for registered AppleTalk devices |GUI |
| |on an AppleTalk-based network. | |
|Browmon.exe |Monitors the status of browsers on selected domains. Browsers |GUI |
| |are shown on a per-domain and per-transport basis. | |
|Browstat.exe |Finds out whether a browser is running. This utility also |CMD |
| |provides information about the state of the browser in a | |
| |workgroup, including the name of the master browser. | |
|Clip.exe |Copies standard input to clipboard. |CMD |
|Compreg.exe |Compares remote and local registry keys. |CMD |
|Delprof.exe |User profile deletion utility. |CMD |
|Delsrv.exe |Unregisters a service with the Service Control Manager (SCM). |CMD |
|Dhcploc.exe |Detects unauthorized DHCP servers on a subnet. |CMD |
|Diskmap.exe |Produces a detailed report on physical disk information from |CMD |
| |the registry. | |
|Disksave.exe |Saves master boot record information. |CMD |
|Dommon.exe |Domain monitoring tool that displays the domain controller name|GUI |
| |and a list of trusted domains, plus various status errors. | |
|Drivers.exe |Lists information about loaded drivers from the command line. |CMD |
|Dskprobe.exe |Disk sector viewing and editing tool. Can be run remotely from |GUI |
| |the command line to create a .dsk report that can be viewed on | |
| |a local system. Can be used to replace the master boot record, | |
| |repair damaged partition table information, and repair or | |
| |replace damaged Partition Boot Sectors or other file system | |
| |data. | |
|Dumpel.exe |Dumps event log information to text file. |CMD |
|Exctrlst.exe |Gives information on the Extensible Performance Counter DLLs |GUI |
| |that have been installed. | |
|Filever.exe |Displays version information on executable files. |CMD |
|Filewise.exe |Checks for corruption and changes in files and generates a |GUI |
| |32-bit cyclic redundancy check (CRC). | |
|Getmac.exe |Gets LAN media access control address information locally and |CMD |
| |remotely. | |
|Kill.exe |Kills tasks or processes from the command line. |CMD |
|Local.exe |Displays members of local groups on remote servers or domains. |CMD |
|Logevent.exe |Event logging utility. |CMD |
|Monitor.exe |Performance data logging server and configuration tool. |CMD |
|Netclip.exe |Views the contents of another computer's Clipboard. |GUI |
|Netsvc.exe |Used to remotely start, stop, and query the status of services |CMD |
| |from the command line. | |
|Nettime.hqx |Syncs Macintosh clocks to an AppleShare server on the network. |CMD |
|Netwatch.exe |Shows which users are connected to shared folders on local and |GUI |
| |remote servers. It also allows you to disconnect users and | |
| |unshare folders. | |
|Nlmon.exe |Use to list and test trust relationships. |CMD |
|Pdlcnfig.exe and |Performance Data Log Service. This tool logs data from |Service |
|Pdlsvc.exe |performance counters to tab-separated or comma-separated | |
| |variable files. It lets you choose which performance counters | |
| |you want to log, and starts new log files automatically at | |
| |intervals you select. | |
|POSIX utilities |POSIX utilities — some now run on Windows NT natively as |CMD |
| |Win32®-based applications, and many support remote operation. | |
|Pulist.exe |Tracks what processes are running on local or remote computers.|CMD |
|Pviewer.exe |Windows NT process viewer displays information about a running |GUI |
| |process and allows you to stop (kill) processes. | |
|Rcmd.exe and Rcmdsvc.exe|Remote command service for secure remote command access to |CMD |
| |servers. | |
|Reg.exe |Adds, changes, deletes, lists, and performs other operations on|CMD |
| |registry entries from the command prompt or a batch file. | |
|Regback.exe |Registry backup program. |CMD |
|Regdmp.exe |Writes all or part of the Windows NT registry to the standard |CMD |
| |output (STDOUT) format that is suitable for input to REGINI. | |
|Regfind.exe |Searches for and replaces data, key names, or value names in |CMD |
| |the Windows NT registry. | |
|Regini.exe |Add keys to the Windows NT registry by specifying a registry |CMD |
| |script. | |
|Regrest.exe |Restores registry hive files from backup copies. |CMD |
|Remote Console |A client/server application that you can use to run a remote |CMD |
| |command-line session. It resembles a Telnet session under UNIX.| |
| |In this command-line session, you can launch any other | |
| |applications remotely. When you run Remote Console, the client | |
| |sends all keyboard events to the Remote Console server so that | |
| |these events are simulated in the CMD console on the server | |
| |side. | |
|Remote.exe |Remote command-line access that allows you to run command-line |CMD |
| |programs on remote computers. You can also use REMOTE to | |
| |distribute the processing requirements for a particular task | |
| |across several computers. Note: This tool does not support | |
| |security features. | |
|Rkillsrv.exe, |Enumerates and kills processes on a remote computer. |GUI, CMD, |
|Wrkill.exe, and | |Service |
|Rkill.exe | | |
|Robocopy.exe |Robust file copy utility that simplifies the task of |CMD |
| |maintaining an identical copy of a folder tree in multiple | |
| |locations, either on the same computer or in separate network | |
| |locations. | |
|Runext.exe |Shell extension adds a Run command to the context menu for |GUI |
| |files that are right-clicked in Explorer. | |
|Scanreg.exe |Registry GREP enables you to search for any string in keynames,|CMD |
| |valuenames, and/or valuedata in local or remote registry keys | |
| |in both Windows NT and Windows 95 operating systems. | |
|Sclist.exe |Shows currently running services, stopped services, or all |CMD |
| |services on a local or remote computer. | |
|Scopy.exe |File copy with security features |CMD |
|Showdisk.exe |Shows disk information by displaying the registry subkey |CMD |
| |HKEY_LOCAL_MACHINE\System\Disk. This subkey contains | |
| |information about each of the primary partitions and logical | |
| |drives defined on the system. | |
|Srvinfo.exe |Displays useful information about a remote server such as |CMD |
| |service state, service pack installed, and more. | |
|Srvinstw.exe |Service Installation wizard simplifies installing or deleting |GUI |
| |services and device drivers on local and remote systems. | |
|Textview.exe |A GUI-based tool for quickly viewing text files on local or |GUI |
| |shared drives. | |
|Vi.exe |UNIX-style line editor. |CMD |
|Winat.exe |Command Scheduler can be used to schedule commands on a local |CMD, GUI |
| |or remote computer to occur once or at regular intervals in the| |
| |future. | |
|Windiff.exe |Displays differences, using CRC, between files and directories.|GUI |
|Winschk.exe |Resolves WINS database replication issues. |CMD |
|Winsdmp.exe |Dumps listing of WINS database records. |CMD |
Solving Problems Remotely Using Windows NT Server 4.0 Resource Kit Tools
The Windows NT Server 4.0 Resource Kit includes many management and diagnostic tools that support remote operation or can be used over the network. When used with the tools built into Windows NT Server, the Resource Kit tools can provide a powerful solution to the challenges of diagnosing and solving problems remotely. The next subsection describes three examples from the many possible uses for these tools.
Example1: Using the Remote Console to Remotely Check the Status of Services and Machine State
Often, administrators are faced with monitoring, maintaining, and sometimes troubleshooting service failures at remote locations. The Windows NT Server 4.0 Resource Kit offers several tools that can simplify this task.
These tools include:
• Service Monitor (SRVMON), which can send e-mail or pages when a service starts or stops.
• SCLIST, which shows services running or stopped on a local or remote computer.
• SRVINFO, which shows a variety of useful information about the state of a local or remote server and its services.
This example uses the SRVINFO tool in conjunction with the Remote Console tool and describes how these tools can help an administrator solve a service problem quickly. Remote Console is a client/server application that you can use to run a remote command-line session. In this command-line session, you can start any other application remotely. A Remote Console session resembles a Telnet session on UNIX. The Remote Console Server service starts a Cmd.exe process for each client connection (CMD is the command-line interpreter). Remote Console then takes full control of the console on which CMD is running and notifies the client of any video memory change to that console. Remote Console does not redirect standard output, but directly takes control of video memory. Therefore, you can use this tool to remotely run any command-line program that uses video memory, such as EDIT. When you run Remote Console, the client sends all keyboard events to the Remote Console server so that these events are simulated in the CMD console on the server side.
Another valuable feature of Remote Console is that it supports logon validation for security and encrypts the password. By default, Remote Console clients are limited to members of the Administrators group, and data encryption is enforced if you use the rclient /encrypt option. Figure 7 shows the logon sequence from the Remote Console client component.
[pic]
Figure 7. Logon Sequence from Remote Console Client
In this example, the administrator has determined that he has a printing problem on one of the print servers that is located at a remote site. One of the symptoms of this problem is that the Printers folder does not show up or function remotely when he connects to the server. The administrator could use Event Viewer to look for any events that might indicate the cause of the problem. However, the administrator has other tasks that he needs to perform locally on the server, so he chooses to run a Remote Console session so that he can operate as though he were sitting directly at the server’s console.
The administrator has opened a command prompt and connected to the print server previously. To gather status about the print server now he simply needs to use SRVINFO with the server’s name, as is shown in figure 8. SRVINFO gathers the information remotely from the system.
[pic]
Figure 8. SRVINFO Used on Remote Console
The administrator solves the problem by examining the information provided by SRVINFO. In this case, the Spooler service is stopped. This explains why the Printers folder cannot be seen remotely. To solve the problem, the administrator must restart the Spooler service. Because he is already on the network, the administrator could restart the service by using the Server Manager tool that is built into Windows NT. However, our administrator prefers to use command-driven tools, and—because he has some other management tasks that he needs to perform on the server locally—he uses the Remote Console client to send the command net start spooler, which solves the problem and restores the print server functionality. He then performs his other management tasks and disconnects from the system.
It should be noted that SRVINFO can be used to gather other useful server information, such as system uptime, IP address, name of the acting PDC for the domain, the installed service pack, information about disk space, and so forth. If you Use SRVINFO with the optional –d switch, it provides driver information as well. SRVINFO can also provide the status of a service if it has an access violation and needs to be restarted or debugged.
Note: If you do not have administrative access to the remote system, most of the information usually provided by SRVINFO will not be available.
Example 2: Using Remote.exe and Built-in Debugging Tools to Remotely Debug a System Stop Error
When Windows NT encounters critical errors, such as hardware problems, inconsistencies within data necessary for its operation, or other similar errors, the operating system processes the error based on the information entered in the Recovery dialog box. If the user did not select Automatically reboot in the Recovery dialog box, Windows NT displays a blue screen containing error information, and then stops.
Preparing to Debug a Stop Screen
This example describes procedures for resolving a system stop error and uses the following terminology:
• Target computer refers to the computer on which the stop error occurs. This computer is the one that needs to be debugged. It can be a computer located within a few feet of the computer on which you run the debugger, or it can be a computer that you dial in to through a modem.
• Host computer refers to the computer on which you run the debugger. This computer should run a version of Windows NT that is at least as recent as the one on the target computer.
There are three approaches you can take to finding the cause of kernel stop errors:
• Set up a remote debugging session with Microsoft Technical Support. You will need to do this if you can’t generate a memory dump file or if the target computer halts and displays a STOP screen. The connection process involves configuring your target computer for a connection (modem to modem) to a host computer located at Microsoft.
• Set up a local debugging session with Microsoft Technical Support by using a Remote Access Service (RAS) server. You will need to do this if you can’t generate a memory dump file or if the target computer halts and displays a STOP screen. The connection process involves using a null modem cable to configure both your target computer and your host computer. The host is then networked to a RAS server and the debugging information is sent to Microsoft over an asynchronous connection. You can also analyze the debugging information at your host computer.
• Set up your target computer to write the contents of its RAM to a memory dump file when a kernel STOP error occurs. You can then use the dump analysis utilities to analyze the memory dump, or send the memory dump file to technical support personnel for their analysis. You enable this option through the Recovery options found on the Startup/Shutdown tab of the System tool in Control Panel.
The Windows NT kernel debuggers (i386kd.exe, Alphakd.exe, Mipskd.exe, and Ppckd.exe) are 32-bit executable files that are used on the host computer to debug the kernel on the target computer. Each host hardware platform has its own set of utilities, which are provided on the Windows NT product compact disc in the Support\Debug folder.
You can use the kernel debuggers for either remote or local kernel debugging. If you use local kernel debugging, the host computer is located within a few feet of the target computer, and the two computers communicate through a null modem serial cable. If you use remote kernel debugging, the host computer can be at any distance from the target computer because communication takes place through modems. The host and target computers send debugging information back and forth through their communications ports. The ports on both computers must be configured to pass data at the same rate in bits per second (bps).
Preliminary Steps
After a blue screen error message appears, record the important information in the message, and then restart the computer. (You may need to configure the target computer for local or remote debugging, and restart it a second time.) You can then continue running Windows NT until the message is displayed again.
After the blue screen message is displayed the second time, call your technical support group and request debugging assistance. Your technical support group can decide whether to debug the kernel STOP error locally or remotely and will instruct you on how to configure your system appropriately.
If you decide to use the kernel debugger to analyze the kernel STOP error, you need to set up the host and connect your host and target computers. To do this, you use either a null modem cable for a local debugging session or a modem cable for a remote debugging session. Before you can start debugging, you must complete several steps.
Windows NT combines the speed and smaller size of “free” (released) versions with the debugging capabilities of the “checked” versions. All executable files, drivers, dynamic-link libraries, and other program files in Windows NT are the free versions. However, each program file has a corresponding symbol file, which contains the debugging code that is normally part of the checked file. These symbol files are on the Windows NT Server product compact disc, in the Support\Debug\Platform\Symbols folder (where Platform is i386, Alpha, MIPS, or PowerPC). Within each Symbols directory, there is one directory for each type of file (such as .exe, .dll, and .sys).
This structure is referred to as a symbol tree and is shown in the table below.
|Directory |Contains Symbols For |
|ACM |Microsoft Audio Compression Manager files |
|COM |Executable files (.com) |
|CPL |Control Panel programs |
|DLL |Dynamic-link library files (.dll) |
|DRV |Driver files (.drv) |
|EXE |Executable files (.exe) |
|SCR |Screen-saver files |
|SYS |Driver files (.sys) |
All of the utilities used to debug Windows NT or to interpret memory dump files require a symbol tree containing the symbol files for the version of Windows NT you were running at the time of the error. With some utilities, you need the Symbols folder to be on your hard disk drive in the %Systemroot% folder. With other utilities, you can specify the path to the Symbols folder as a command-line option or in a dialog box.
Setting up a Remote Debugging Session on an Intel-based Target Computer
The following are steps to prepare a target system for debugging:
1. Set up the modem connection.
2. Configure the target system for debugging.
3. Set up a symbol tree on the host system.
4. Set up the debugger on the host system.
5. Start the debugger on the host system.
The process of remote debugging occurs when two computers are connected by modems and a telephone line. This connection allows the target and host computers to communicate by using a special debugging API and protocol.
To configure a system for remote debugging, change the boot options so that Windows NT loads the kernel debugger. On an x86-based platform, you do this by editing the Boot.ini file. On a RISC-based system (DEC Alpha, MIPS, and PowerPC processors), change the boot options in the firmware menu. You must also connect an external modem to the appropriate COM port on the target computer, and connect an inbound telephone line to the modem.
Booting the Target Computer
If the target computer stops at a blue screen error message every time you boot it or does not keep running long enough for you to edit the Boot.ini file to enable the debugger, try these options:
• If your boot partition is FAT, start MS-DOS from a boot floppy disk and use the MS-DOS®–based editor to edit Boot.ini.
• If your boot partition is NTFS (or HPFS, if you are running Windows NT version 3.1 or 3.5), install Windows NT on a different partition and boot from that partition. (You need to use this method because you cannot access files on an NTFS or HPFS partition from MS-DOS.)
• If you previously created a Windows NT-based boot recovery disk for the workstation that has the problem, you can use this disk on another computer to edit the Boot.ini file, and then boot the target computer. (See the Resource Kit for procedures on how to build a boot recovery disk.)
Setting Up the Modem on the Target Computer
To set up a remote debugger session, connect an external modem to the target computer, and then reconfigure the modem parameters to meet the requirements of the kernel debugger. To configure the modem, you must be able to run Terminal.exe or some other communications program. If you are unable to run these programs on the target computer, connect the modem to a computer that is close to the target computer. Make sure you can move the modem back to the target computer without losing power to the modem, or store the settings in the modem’s non-volatile RAM (NVRAM). An internal modem may not work because rebooting the system resets the configuration changes you have made to the modem.
The modem must be connected to a spare COM port and must be configured as shown in the following table:
|Setting |Value |
|Auto answer mode |On |
|Hardware compression |Disabled |
|Error detection |Disabled |
|Flow control |Disabled |
|Baud rate |9600 bits per second (bps) for x86-based system |
| |19,200 bps for RISC-based system |
Consult your modem documentation for the correct string values to send to the modem during the configuration process.
The following table shows what functions to set when configuring your modem for a remote debugging session. The value column shows U.S. Robotics V.Everything modem command values as an example. Note that other modem models or other manufacturers may require different values.
|Function |Value |
|Set back to factory defaults |AT&F |
|Disable transmit data flow control |AT&H0 |
|Disable receive data flow control |AT&I0 |
|Disable data compression |AT&K0 |
|Disable error control |AT&M0 |
|Auto answer on |ATS0=1 |
|Disable reset modem on loss of DTR |AT&D0 |
|Write to NVRAM |AT&W |
Configuring the Modem
1. Connect the modem to an unused COM port on the target computer or on another computer that is close enough to the target computer to connect by a standard modem cable.
Note: If you connect the modem to a computer other than the target computer, be sure that you can move the modem back to the target COM port without removing power from the modem.
2. Run Terminal.exe or some other communications program to configure the modem parameters.
3. Set the modem speed to 9600 bps. See your modem documentation for instructions.
4. Turn off all hardware compression, flow control, and error detection. Procedures for this vary widely from modem to modem. See your modem documentation for the correct strings to send to the modem.
5. Enable auto-answer by sending the string ATS0=1 to your modem. (Consult your modem documentation to verify that this will work with your modem.)
6. If the modem was configured on a computer other than the target computer, move it to the target computer without disconnecting the power from the modem.
Note: As an alternative, you can store the settings in the modem's NVRAM, which should save the settings if the modem loses power.
Debugger Options
The following table lists the boot options that can be used to configure the system for debugging. These options are the same on Intel x86 and RISC platforms, but the slash mark (/) is not required on a RISC platform.
|Debug Option |Function |
|/Debug |Causes the kernel debugger to be loaded during boot and kept in memory at all |
| |times. This means that a support engineer can dial into the system being debugged |
| |and break into the debugger, even when the system is not suspended at a kernel STOP|
| |screen. |
|/Debugport |Specifies the serial port to be used by the kernel debugger. If no serial port is |
| |specified, the debugger will default to COM2 on Intel x86-based computers and to |
| |COM1 on RISC computers. |
|/Crashdebug |Causes the kernel debugger to be loaded during boot but swapped out to the pagefile|
| |after boot. As a result, a support engineer cannot break into the debugger unless |
| |Windows NT is suspended at a kernel STOP screen. |
|/Baudrate |Sets the speed that the kernel debugger will use in bits per second. The default |
| |rate is 19,200 bps. A rate of 9600 bps is the normal rate for remote debugging over|
| |a modem. |
When you use the Debugport or Baudrate options, you do not need to use the Debug option, because Windows NT assumes that the computer will load in Debug mode. You must use at least one of the options described in the table above to configure a computer for remote debugging. Otherwise, Windows NT does not load the debugger.
Editing the Boot.ini File on the Target Computer
To configure a target system for remote or local remote debugging, edit the boot options in the Boot.ini file to tell Windows NT to load the kernel debugger. To set up the target computer on an Intel x86-based computer, edit the Boot.ini file by using a standard ASCII text editor and add the appropriate debugger options to the file.
The Boot.ini file is located in the system root directory (usually C:\) and has the Hidden, System, and Read-only attributes set. These attributes must be changed before the file can be edited.
To change the attributes of the Boot.ini file, type the following at a command prompt:
attrib -s -h -r c:\boot.ini
To restore the Read-only, Hidden, and System attributes when you finish debugging the system, type the following at a command prompt:
attrib +h +r +s c:\boot.ini \
Configuring the Boot Options in the Boot.ini File
To configure the target computer for remote or local debugging, add the /Debug and /Baudrate options to the Boot.ini file. If you cannot use the default COM port (COM2) for debugging, use /Debugport=COMx where x is the COM port number. Use the MS-DOS–based Editor to edit the Boot.ini file.
Follow these steps to complete this process:
1. At a command prompt, type edit boot.ini.
2. Select the startup option that you normally use, and add the /Debug option at the end of the line.
3. To specify the communications port, add the option /Debugport=comx, where x is the communications port that you want to use.
4. Add the option /Baudrate=9600.
5. Save the Boot.ini file, and quit the text editor or the MS-DOS-based editor.
6. Restart the computer to run under Windows NT.
Your target system should now be ready for debugging, and the technical support group can now call the modem to establish the remote debugging session. If you are also configuring the host system, you are not completely finished. The next section discusses how to configure the host system for debugging.
Setting Up Debugging on the Host Computer
To set up the debugger on the host, first ensure that you have the correct files available. Copy these files from the Support\Debug\Platform folder (where Platform indicates the platform of the host computer—i386, Alpha, MIPS, or PowerPC) from the Windows NT 4.0 compact disc to a debug folder on the hard disk drive. Some files that you copy from the directory must match the platform of the target computer, as described in the following table. These files are necessary for kernel debugging.
|File |Source List |
|Platformkd.exe |Alphakd.exe |
| |I386kd.exe |
| |Mipskd.exe |
| |Ppckd.exe |
|Imagehlp.dll | |
|Kdextplatform.dll |Kdextalp.dll |
| |Kdextx86.dll |
| |Kdextmip.dll |
| |Kdextppc.dll |
The platform in italics matches the platform of the target computer. For example, if your host computer is an Intel 486 computer and the target computer is a MIPS RISC-based system, copy the following files from the Support\Debug\i386 folder:
• Mipskd.exe
• Imagehlp.dll
• Kdextmip.dll
After you set up the symbol tree and copy the necessary files to it, use a batch file to set the following environment variables on the host:
|Variable |Purpose |
|_NT_DEBUG_PORT |COM port being used on host for debugging. |
|_NT_DEBUG_BAUD_RATE |Maximum baud rate for the debug port. On x86-based computers, the |
| |maximum is 9600 or 19,200 bps for modems, 19,200 bps for null-modem |
| |serial cables. On RISC-based computers, rate is always 19,200 bps. |
|_NT_SYMBOL_PATH |Path to symbols directory. |
|_NT_LOG_FILE_OPEN |Optional, the name of the file to which to write a log of the debug |
| |session. |
After you set these environment variables, you can start the host debugger.
Note: Setting the _NT_LOG_FILE_OPEN variable does not always result in a log file being written. You can also create the log file from the debugger. The command format is: .logopen pathname. You may also need to issue the !reload command to get this to work.
Starting the Debugger on the Host Computer
You can start the host debugger from the command line or a batch file by using the name of the executable file as the command. Each debugger supports the following command-line options:
|Option |Action |
|-b |Causes the debugger to stop execution on the target computer as soon as possible by causing a |
| |debug breakpoint (INT 3). |
|-c |Causes the debugger to request a resync on connect. Resynchronization ensures that the host and|
| |target computers are communicating in sequence. |
|-m |Causes the debugger to monitor modem control lines. The debugger is only active when the |
| |carrier detect (CD) line is active; otherwise, the debugger is in terminal mode, and all |
| |commands are sent to the modem. |
|-n |Causes symbols to be loaded immediately, rather than in a deferred mode. |
|-v |Indicates verbose mode; displays more information about such things as when symbols are loaded.|
|-x |Causes the debugger to break in when an exception first occurs, rather than letting the |
| |application or module that caused the exception deal with it. |
The most commonly used options are -v (verbose) and -m (for modem debugging). Generally, the best way to start the debugger is to create a batch file with the necessary commands to set the environment variables, followed by the command to start the correct kernel debugger.
Using the Remote Utility from the Windows NT Resource Kit to Start the Debugger
If the host computer is connected to a network, you can use the remote utility, included in the Windows NT Server or Windows NT Workstation Resource Kit, to start the debugger. Remote is a client/server utility that provides remote network access by means of named pipes to applications that use STDIN and STDOUT for input and output. Users at other computers on the network can then connect to your host debugger session and view the debugging information or enter commands.
Note: The Remote utility does not support security features such as logon validation.
The syntax for starting the server (host) end of the remote session is as follows:
remote /s "command" unique_id [/f foreground_color|/b background_color]
For example:
remote /s "i386kd -v" debug
To end the server session, enter the @K command.
To interact with this session from some other computer, use the remote /c command. The syntax of this command is as follows:
remote /c server_name unique_id [/l lines_to_get|/f foreground_color|/b background_color]
To exit from the remote session on a client and leave the debugger running on the host computer, enter the @Q command.
For example, if you used the remote /s command to start a session with the ID debug on the host computer Server1, you can connect to it with the command:
remote /c server1 debug
Below is an example of using Remote.exe to remotely debug a stop screen, assume the following:
• Debugging needs to take place over a null-modem serial cable on COM2.
• The symbols are on a compact disc on drive E.
• A log file called Debug.log is to be created in the Temp folder on drive C.
Note: The log file is important because it holds a copy of everything you see on the debug screen during your debug session. All input from the person doing the debugging, and all output from the kernel debugger on the target system, is written to the log file.
Sample Batch File for Doing Local Debugging
The following is a simple batch file used for local debugging.
REM Target computer is local
set _NT_DEBUG_PORT=com2
set _NT_DEBUG_BAUD_RATE=19200
set _NT_SYMBOL_PATH=e:\support\debug\i386\symbols
SET _NT_LOG_FILE_OPEN=c:\temp\debug.log
remote /s "i386kd -v" debug
The last line of the batch file uses the remote utility to start the host debugger. If you use this, users of Windows NT-based computers who are networked to the host computer (and who have a copy of the remote utility) can use the command to connect to the debug session.
remote /c computername debug
where computername is the name of the host computer.
To allow remote debugging, which requires the use of a modem, begin with the batch file in the previous example. Change the baud rate to 9600, and add the -m switch to the last line. The sample batch file for doing remote debugging is as follows:
REM Target computer is remote from the host
set _NT_DEBUG_PORT=com2
set _NT_DEBUG_BAUD_RATE=9600
set _NT_SYMBOL_PATH=e:\support\debug\i386\symbols
SET _NT_LOG_FILE_OPEN=c:\temp\debug.log
remote /s "i386kd -v -m" debug
You run the batch file from the directory that contains the debugger files. When you start the debugger, one of two screens appears, depending on whether you are debugging locally or remotely. At this screen, you can press CTRL+C to gain access to the target computer (if it is still running). If the target computer is currently stopped at a blue screen error message, you should be able to gain access automatically. If you have any problems, press CTRL+R to resynchronize the host computer and the target computer.
If you are debugging remotely, the same screen as shown for local debugging appears, with the following extra message: “KD: No carrier detect - in terminal mode.”
This is shown in Figure 11, next.
[pic]
Figure 11. Remote Debugging in Terminal Mode
In this case, the debugger is in terminal mode, and you can send any of the standard AT commands to your modem. Begin by sending commands to disable hardware compression, flow control, and error correction. These commands vary from modem to modem, so consult your modem documentation. After you connect to the target system and have a carrier detect (CD) signal, you are returned to the debugger.
For More Information on Remote Debugging
For more information on remote debugging and the use of the Remote tool and other tools provided in the Windows NT Resource Kit, see the following sources:
• The Rktools.hlp file in the Windows NT Resource Kit.
• the information on remote debugging in Chapter 39 of the Windows NT Workstation 4.0 Resource Guide (included with the Resource Kit).
• Microsoft’s online Knowledge Base at ; see the following articles:
• Q129845 – Blue Screen Preparation Before Calling Microsoft
• Q148659 – How to Set Up Windows NT Debug Symbols
• Q148954 – How to Set Up a Remote Debug Session Using a Modem
• Q151981 – How to Set Up a Remote Debug Session Using a Null Modem Cable
• Q121543 – Setting Up for Remote Debugging
Example 3: Using Client-Based Network Tools and Web Management
Figure 9 shows which tools are installed from the client-based network tools included with Windows NT Server 4.0 and the Windows NT Server 4.0 Resource Kit. These tools allow administrators to do the same remote management and diagnostic tasks from Windows NT Workstation 4.0 as they can from Windows NT Server.. A subset of these tools—also known as Nexus—are available for Windows 95 on the Windows NT Server 4.0 compact disc.
Note: For more information about Web Management, refer to the next section, “Remote Management Over the Internet.”
[pic]
Figure 9. Client-based Administrative Tools
If your organization has servers or users in remote locations, you can use these tools to manage these Windows NT domains and servers across the Internet. You can use the Internet as a WAN and allow users at remote locations to access both file and printer services as if they were on the LAN. To do this, you must modify the LMHOSTS file on the client computer. For more information about how to do this, see the Microsoft Knowledge Base article Q143175, “Server Management, File and Print Services Over the Internet,” which can be found online at .
Installing the Resource Kit Tools
To install the Resource Kit tools, start the appropriate setup program for your system. The setup program is located in the Clients\Srvtools folder on the Windows NT Server 4.0 compact disc or in the Apps\clients folder on the Windows NT Server 4.0 Resource Kit compact disc. Follow the instructions on the screen to complete the installation.
For more information about using these tools, see each tool's Help file. See the “Remote Management using Windows NT Server Tools” section in this white paper for information about what each of the server management tools is used for and what tasks can be performed remotely.
Remote Management Over the Internet
In addition to tools included with Windows NT and with the Windows NT Resource Kits, you can use Web Management for Microsoft Windows NT Server to manage your system remotely. Web Management enables you to use an Internet browser running on Microsoft Windows, Apple Macintosh, or UNIX to remotely manage Microsoft Windows NT Server. Web Management is not designed to replace existing management tools for Windows NT Server. Instead, it is designed to enable you to perform limited management tasks when you are away from your usual workstation and do not have access to traditional tools.
[pic]
Figure 10. Web Management for Microsoft Windows NT Server
Web Management is designed to work in conjunction with Microsoft Internet Information Server 2.0 or later. The Web Management tool is designed for use by for Windows NT Server administrators who have performed tasks with the regular management tools available in Windows NT 3.51 and Windows NT 4.0.
Remote Management Tasks and Tools
Web Management supports the tasks most commonly performed by roaming administrators, as shown in the following table.
|Management Area |Administrative and Diagnostic Task |
|Account Management |Create, delete user accounts, and modify their properties. |
| |Add and remove users to and from groups. |
| |Add workstations to the domain. |
|Share Management |Create, view, and change permissions on shares for all installed |
| |file services. |
|Session Management |View and delete one or all current sessions. |
| |Send messages to current users of the server. |
|Server Management |Shut down (restart) the server. |
| |Change service/driver configuration. |
| |View System, Application, and Security log events. |
| |View server configuration, performance data, and statistics. |
|Printer Management |List print queues and jobs in each queue. |
| |Pause queue or specific print job. |
| |Flush queue or specific print job. |
Security
Web Management supports several modes of security. Each server you administer must support Basic authentication, Windows NT Challenge Response security, or both. In addition, Secure Sockets Layer (SSL) can be used with either or both of these modes of security for encryption of your session.
Installing and Starting the Software
You can install the Web Management software on any server that runs Windows NT Server 4.0 and Microsoft Internet Information Server (IIS) 2.0 or later. Installing the Web Management software on the server causes the server to publish Web pages that include forms you can use to manage that particular server.
You can then use any Web browser that supports either Basic or Windows NT Challenge Response authentication. If you use Windows NT Challenge Response and a browser that supports Windows NT Challenge, you must first log on with a user account that is a member of the Administrators group on the server you want to manage.
To begin managing the server, type the following in the address line of your browser:
This is the only way to start the Web Management tools; you cannot start them by double-clicking a file name or by using “localhost” in place of the real server name.
You can now perform management tasks on the remote server. If you are using Basic authentication (or if you are using Internet Explorer 3.0 and are not already logged on to an administrative account), you will be prompted for a user name and password when you select a task.
Administering User Accounts with Web Management
You can manage a domain’s user accounts with Web Management tools pointed at either the domain’s primary domain controller (PDC) or any backup domain controller (BDC). By default, when you begin to administer user accounts using Web Management tools, only the first 1,024 user accounts are listed in the Web Management list box. A message appears saying that the computer is unable to list all the user accounts, and that only the first 1,024 are listed. This is done to save time, as it can take a while to transmit the names of all the user accounts across the network to the client browser.
Note that even with only some of the user accounts listed, you can still freely add new user accounts. To have more user accounts listed when you administer user accounts, adjust the setting is MaxUsersToDisplay, found in the following subkey:
HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Inetsrv_NTAdmin
More Information About Web Management
You can find additional information about the installation and use of Web Management in the Windows NT Server 4.0 Resource Kit Resource Guide or on the World Wide Web at .
Solving Problems Remotely Using Microsoft Add-On Tools
Microsoft NetMeeting
Microsoft NetMeeting is a standards-based product that provides a conferencing solution for the Internet and corporate intranet. It is included as one of the Microsoft Internet Explorer add-ons. It allows you to communicate using both audio and video, collaborate using almost any Windows-based application, exchange graphics on an electronic whiteboard, transfer files, use a text-based chat program, and share applications.
NetMeeting provides an unsecured method of sharing applications and a simple method of remote desktop control. Although not recommended for use on a server because of limited security features, NetMeeting does provide a simple, cost-effective solution for customers who need graphical desktop remote diagnostics capabilities on Windows NT Workstation 4.0 and Windows 95-based systems.
Customers who need advanced full-featured graphical desktop remote control with powerful security and management features should consider Microsoft Systems Management Server. It offers additional management features and security far beyond the capabilities NetMeeting provides.
Note: Administrators should also consider that using NetMeeting for remote desktop control and collaboration, although not excessive, does consume network bandwidth. Administrators may want to first conduct tests in a non-production environment to see if this tool meets their remote desktop control and bandwidth needs.
By using NetMeeting, users can collaborate and share information with two or more conference participants in real time. Users can share applications on their computers and work together by allowing other conference participants to see the same information on their screens. NetMeeting 2.x supports the H.323 standard for audio and video conferencing, which includes the H.263 video codec. H.323 allows NetMeeting to interoperate with other compatible video telephone clients, such as the Intel Internet Video Phone. NetMeeting produces high-quality, real-time video images using a standard 28.8 Kbps modem Internet connection, IP over ISDN connection, or LAN connection. NetMeeting supports video capture cards and cameras that are compatible with Video for Windows drivers. This includes most commonly available video hardware.
NetMeeting is both a client and a platform. The NetMeeting client enables users to experience the benefits of a real-time, multipoint communication and collaboration program. The NetMeeting platform enables third-party vendors to integrate conferencing features into their own products and services. To support this dual purpose, Microsoft implemented NetMeeting capabilities using an open architecture of inter-working components. Each component communicates with and passes data to and from the component layer above and below. This open architecture means that vendors can easily develop products and services that build on the NetMeeting platform and interoperate with NetMeeting client conferencing features.
NetMeeting Architecture Components
At the core of the NetMeeting architecture is a series of data, audio, and video conferencing and directory service standards. These standards work together with transport, application, user interface, and ActiveX® controls to form the NetMeeting architecture, shown below.
[pic]
Figure 12. NetMeeting Architecture
Example: Using NetMeeting for Remote Diagnostics
A corporate help desk provides an example of how NetMeeting features can be used to remotely diagnose a problem. Many corporations today have branch offices around the world, but centralize their help desk operations at their corporate headquarters. Support requests are often submitted to these help desks by internal e-mail or the telephone. Although this works effectively at the corporate headquarters, it often presents a challenge for the branch office, which may be at some distance from corporate headquarters. The branch office may not have experienced help desk staff on location to solve problems, and the corporate help desk cannot immediately dispatch a system engineer to diagnose the problem. In these cases, NetMeeting can provide the eyes and ears to the corporate help desk staff even though the help desk may be hundreds or even thousands of miles away.
In our example, an end user has been experiencing problems with her display, and she cannot resolve the problem herself. Strange colors appear when she starts certain graphical programs; the colors look drab and uninviting, and, to the end user, it appears that something has gone wrong with her computer monitor. She decides to contact the corporate help desk staff and ask for assistance. She composes a piece of e-mail to the help desk staff with details explaining the problem with the computer monitor and that she believes it is not working properly because it will only display certain colors on the screen. The help desk staff receives the e-mail but because of inadequate information and the distance involved between the help desk staff and the end user, cannot resolve the problem over e-mail. The help desk staff decides to contact the end user over the telephone to get additional details about the problem.
After discussing the problem with the end user, the help desk technician cannot conclusively pinpoint the monitor as the cause of the problem. And, because the end user is not an experienced computer user, attempting to diagnose the problem becomes a frustrating and time-consuming process. The help desk technician cannot see what the end user is doing on her computer, and the end user cannot effectively communicate what she is doing and seeing on the screen. The help desk staff is faced with contacting a third-party computer service organization to replace the monitor. However, this would be expensive and may not resolve the problem. The other option is to continue to work remotely with the customer to try to pinpoint an exact cause. The help desk technician decides on the latter option.
To see exactly what the end user is experiencing, the help desk staff decides to use Microsoft NetMeeting.
Starting NetMeeting on Remote and Local Computers
Note: The example outlined here assumes that Windows NT 4.0 with Service Pack 3 and Microsoft NetMeeting version 2.1 are running on the local and remote systems. Clients using Windows 95 will see slightly different screens, but the basic principles outlined here still apply.
The help desk staff contacts the end user by telephone and explains how to launch NetMeeting on her computer. The help desk staff gathers the end user’s computer name, e-mail name, and IP address, as this information is needed to contact the end user when using NetMeeting.
Establishing Connectivity to the Corporate Network
The help desk staff assists the end user to establish a Dial-Up Network (DUN) connection to her corporate network. (If the end user was already on the corporate network through a LAN or WAN connection, skip this step.)
Note: If you are using an ILS server, you can find and connect to the other party through the directory using a variety of information such as e-mail name, first or last name, and much more. See the NetMeeting Resource Kit located on for more details on the ILS server.
Connecting to the End User’s System Using NetMeeting
The next step involves connecting the end user’s system by using the Call button or Call menu, and then clicking the New Call option. In the New Call dialog box, the help desk staff type the computer name in the address field, and selects Network (TCP/IP) in the Call using field.
[pic]
Figure 13. NetMeeting New Call Screen
Sharing Applications
After you have successfully connected to the remote computer, you need to configure sharing for the applications that will be needed to diagnose the problem. The help desk staff no longer needs to use the telephone to communicate with the end user because NetMeeting provides a chat application that allows both parties to communicate through the keyboard. Further communication with the end user at this point can be continued by telephone conversation or handled completely through the features of NetMeeting.
In our example, the help desk staff asks the end user to start the My Computer application and the graphical program (Microsoft Internet Explorer) that she was using when she experienced the problem.
After the applications are started, the next step is to have the remote side (in this case, the end user) share the applications. The help desk technician asks the end user to click the Share button. The menu shown in Figure 14 appears.
[pic]
Figure 14. Share Menu
The help desk technician then asks the end user to select the Microsoft Internet Explorer application.
Collaborating
At this point the applications are shared, but some additional steps must be completed before the help desk staff can assume control of the remote applications. NetMeeting requires that that both the remote and local users first grant sharing access by using the Collaborate button. The help desk technician asks the end user to click the Collaborate button and also does the same on the local NetMeeting session. The help desk technician then clicks the new Microsoft Internet Explorer application that appears on the taskbar.
Note: It may not be apparent which applications are being shared remotely. To identify the remotely shared applications, look for those that are displayed on the taskbar as windows with hands below them. In addition, if you use the mouse pointer to hover over the title of the application, the remote user’s name will be displayed. To avoid confusion, it’s a good idea not to start or share too many applications on the local system.
Figure 15 shows a taskbar after the application has been shared and both parties have collaborated.
[pic]
Figure 15. Taskbar After Applications Are Shared
Diagnosing and Isolating the Problem
At this point, the help desk technician has control of the end user’s applications and begins to diagnose the problem. (The technician sees a mirror of what is on the end user’s screen.) After a short time browsing Web pages on the corporate intranet, the help desk staff notices that the color depth is restricted. Many bitmaps are not displayed in more than 16 colors, making the Web pages appear drab. The technician concludes that the end user may be using a low-resolution video driver and that the monitor may not be at fault at all. To verify this assumption, the technician asks the end user if this is the problem she is noticing.
The next step is to verify that the end user’s display configuration is set for a color depth of only 16 colors. The help desk staff asks the end user to go back to the NetMeeting application, click the Share button, and then select My Computer. Sharing My Computer gives the technician complete control of all of the computer's features, allowing the help desk technician to start Control Panel and the Printers folder, and to look at all files located on the hard disk.
Note: To ensure the security of both systems, you should never leave the systems unattended in this state.
After the technician has taken control of My Computer on the remote system, the help desk staff starts Control Panel and then double-clicks the Display icon. The Settings tab confirms the technician’s assumption about the cause of the problem. The end user has her color settings set to 16-color depth, making Web pages displayed in Microsoft Internet Explorer appear drab (see Figure 16).
[pic]
Figure 16. Color Palette with 16 Colors Selected
Fixing the Problem
At this point, the help desk technician has positively identified the problem. The next step is to solve the problem for the end user and to test the results. The technician clicks the Display Type button to identify the video driver and its version number. He finds that the end user is using the generic 16-color VGA-compatible display adapter driver. The next step is to change the display driver to the correct driver with improved color depth.
The technician uses the My Computer application, which is still being shared on the remote computer, to search the hard disk for the correct driver. He quickly determines that the end user does not have the needed display driver on her system. This presents a problem: how can the help desk get the needed driver to the end user quickly without sending someone to her location? The technician can accomplish this task using the File Transfer feature of NetMeeting.
Using the File Transfer feature (see Figure 17), the technician sends the correct display driver to the end user and then assists with the installation.
[pic]
Figure 17. File Transfer Option
File transfers occur in the background, so the help desk technician can continue to work with the end user and can also use the chat or whiteboard features of NetMeeting.
After the file transfer is complete, the technician installs the updated video driver, and restarts the end user’s system. This solves the problem and, in a matter of a few minutes, the technician has the end user back up and running without incurring the expense of sending a systems engineer to her location.
While this example used a fairly simple problem, it does illustrate the diagnostic capabilities of NetMeeting that can be used to solve more complex problems.
Microsoft Systems Management Server
Systems Management Server is a key component in Microsoft's Zero Administration Initiative for the Windows operating system (ZAW). It provides tools such as hardware and software inventory, software distribution and installation, and remote diagnostics to let you better manage your computing environment, be it a few computers or tens of thousands of desktops. Systems Management Server is designed to help system administrators lower their management costs by helping them install and maintain operating systems and applications, discover system configurations, and perform help desk operations. It is a highly scalable, WAN-aware product that integrates with the major enterprise management solutions.
Network Monitor is a component of Systems Management Server that enables you to detect and troubleshoot problems on LANs or on WANs running the Microsoft Remote Access Service (RAS). This section focuses on one aspect of the features of Network Monitor in Systems Management Server—the ability to remotely capture network packets using RAS, the Network Monitor, and the Network Monitor Manager.
Remote Network Troubleshooting with Network Monitor and the Network Monitor Agent
Network Monitor is a network analysis tool for the Windows operating systems. Although Network Monitor is entirely implemented in software, it has a full range of network analysis capabilities, including:
• Capturing frames from the network
• Displaying the parsed frames
• Filtering both on capture and display, to give users the information they need
• Using triggers to control the progress of a capture session
• Capturing on a remote computer
This section focuses on the last feature—the ability to capture frames on a remote computer using the Network Monitor and Network Manager Agent. Remote capturing allows the user to connect to another computer, possibly on another subnet, and capture network frames as seen by that remote computer.
Remote capturing is useful in network administration and troubleshooting situations. Without remote capturing capability, the user is limited to capturing frames that his or her computer sees directly. This can hinder problem resolution if the problem is on the other side of a router or a bridge. With remote capturing capability, a network card on a computer running the Network Monitor Agent can be used as a network resource. Users can capture traffic on any subnet that has a computer with the Network Monitor Agent available to them, including subnets available over RAS.
When discussing Network Monitor, it is important to understand two terms: manager and remote machine. The manager is the local computer with a full Network Monitor installation. The manager is where the administrator sits and performs the connection to an agent, captures frames, views, and analyzes the frames. The system with the remote agent installed and the Network Monitor Agent Service is the remote machine. On the remote machine, the user can only change the password, and start, and stop the service.
The Network Monitor Agent
Network Monitor uses the Network Monitor Agent, running on a remote computer, to capture network statistics from a remote location. While the Network Monitor Agent does not represent a full installation of Network Monitor, it significantly enhances the scope of Network Monitor by enabling it to capture data across more than one network. In addition, when you install the Network Monitor Agent, counters are added to the Windows NT Performance Monitor. You can use the counters for limited monitoring of network performance.
Network Monitor uses the Remote Network Abstraction Layer (RNAL) to connect the Network Monitor Agent. RNAL is a dynamic-link library (DLL) that enables a local installation of Network Monitor to use a remote network adapter card as though the card were locally installed. When Network Monitor connects to the Network Monitor Agent on a remote computer, filters, captures, and triggers function just as they would locally. If you stop a remote capture and display it, the capture’s contents are displayed as though the capture were local.
Network Monitor Agents have password security. You can set a password on the remote agent, and this password will be requested when any Network Monitor Manager tries to establish a connection. This password is originally set null, but you can use the Network Monitor Agent Control Panel tool to change it.
Because of security concerns, by default, the ability to transmit frames is disabled on remote computers. There are two reasons for this. First, users should not be able to transmit frames into somebody else’s subnet. Second, if users transmit too many frames, they could flood the net and be unable to stop the transmission. If the transmit frames feature is needed, it can be configured manually from the Tools menu of the Network Monitor Manager.
Installing the Network Monitor Agent and Network Monitor Manager
The Network Monitor Agent software is included with both Windows NT Workstation and Windows NT Server. To locate the Network Monitor Agent and Manager start Control Panel and click the Network icon.
Windows NT Server includes a limited version of the Network Monitor Manager tool. To locate the Network Monitor Agent, start Control Panel and click the Network Icon. The tool is identified as Network Monitor Tools and Agent..
Note: The limited version of the Network Monitor Manager included with Windows NT Server does not have the ability to connect to remote agents. The full version of the Network Monitor Manager tool described in this document is included and installed with Systems Management Server.
Network administrators who want to have full coverage for all the systems on their network should install the Network Monitor Agent at least once on each subnet. With Systems Management Server, you can determine which computers are on which subnet by querying all computers either by subnet mask or by default gateway. Otherwise, track the subnet information manually and determine where to put the agent.
As an alternative, you can install the agent on each router or bridge in the network. You should also install the agent on computers where you have administrative privileges so that you can access Event Viewer remotely to troubleshoot and identify agent events. See the “Troubleshooting Network Monitor Agent Using the Remote Event Log” section for more information about the events that are generated by the Network Monitor Manager and Agent.
Connecting to a Network Monitor Agent
To capture networking packets on a remote agent, the administrator has to connect to the remote agent and specify the remote agent as the network on which to capture data.
If you connect to the Network Monitor Agent on a computer that has only one network adapter card installed, Network Monitor uses that card to establish the connection to the Network Monitor Agent and perform remote captures. If more than one network adapter card is installed on the remote computer, a dialog box appears and displays a list of the network adapter cards installed on the remote computer. An asterisk appears next to the network adapter card that Network Monitor used to establish the connection. Throughout the remote capture process, this network adapter card maintains the connection, passing frames from the network adapter card on which the Network Monitor Agent is capturing to the network adapter card on the manager of the connection. Unless you want to capture traffic on your local subnet or a subnet to which you are connected by a router, you should choose a card other than the one marked with the asterisk.
When you use Network Monitor to connect to a RAS server that has the Network Monitor Agent installed, you can capture on the RAS server’s subnet. You can use the Network Monitor Agent on a RAS server only if the network adapter card on the RAS server supports promiscuous mode. Promiscuous mode is a state in which a network adapter card detects all the frames that pass over the network. To use RAS to connect to the Network Monitor Agent, use the RAS interface to dial in to the network. If the RAS server does not have the Network Monitor Agent installed, the administrator can still connect to a Network Monitor Agent that is available on the remote network. After you connect to the network, use Network Monitor to connect to the Network Monitor Agent over the established RAS connection.
Note: After you connect to the Network Monitor Agent over a RAS line and you start a capture, you should suspend the connection. In addition, if you are using a modem of 2400 baud or less, choose the Slow Link option in the Network Monitor Agent dialog box.
Capturing Network Packets with the Network Monitor Agent
To the observer, capturing network packets with the agent looks just the same as capturing packets locally, except that statistics are updated less frequently. After the connection is established, you can set filters and triggers, and choose buffer and frame sizes. Each of these items will function as if you were activating them locally.
Capturing Network Packets on a Different Subnet
If you are capturing on one subnet (either locally or on a remote computer), and looking at frames going to and from a computer on a different subnet, you may not be capturing all of the frames that the computer sees. You may only be able to capture connection traffic, and only the connection traffic that passes through the subnet where you are capturing. Routers or bridges are usually configured so that they do not forward broadcasts and multicasts.
To capture all of the traffic going to and from a target computer, try to find a Network Monitor Agent on a computer on the same subnet as the target computer. With Systems Management Server, you can choose which agent to capture on to get the frames desired. Follow these steps:
1. Determine which computer is experiencing a problem (the target computer).
2. Determine the subnet of the target computer by looking at the IP address and subnet mask.
3. From list of available agents, choose one on the same subnet.
If there is not an agent available on the same subnet, your may want to isolate the problem by determining if the problem occurs when the computer communicates with a specific system. After you have isolated these two systems, repeat steps
1 to 3 above.
Even if you perform a capture on the same logical subnet as the target computer, you still may not see all of the traffic if learning bridges are in place. To be absolutely certain of capturing all traffic to or from a target computer, perform the capture on the target computer itself. As long as the network card on the target computer supports the loop-back function, you will be able to capture all of the frames that it sends and receives. If you suspect you are not seeing all of the frames you are interested in, make sure that the capture filter and display filter are set correctly.
Capturing Network Packets on a Router
If you install the Network Monitor Agent on a router, you will be able to capture traffic on either side of the router, or on both sides. However, interpreting the frames captured on a router can be difficult. Keep these two cases in mind:
• The Router Separates Two Physical Subnets
Having a Network Monitor Agent installed in an environment where a router exists with two separate physical subnets can be very useful. If you know which network card on the router is connected to which physical network, you can connect to the router to start a capture, and capture on either network. There is no way to capture on both of the router’s network cards simultaneously from another computer—the Network Monitor Agent only supports one connection. To capture on both sides of a router simultaneously so that you can compare information, capture on different computers on each subnet. (To do this from one local computer, launch two instances of Network Monitor, and connect each instance to a different remote computer). Set the capture trigger to stop the capture at the same time on both remote machines. As an alternative, you could install the full Network Monitor user interface on the router, and then start two instances of Network Monitor on the router, capturing on a different network with each instance of Network Monitor.
• The Router Separates Two Virtual Subnets
This is a router with only one network card. It routes frames that are all on the same physical subnet, but the router is still needed because the computers can’t see each other because of their addresses. If you capture on the router, all frames passing over the router should be there twice: once coming in and once going out. This may be confusing because it is difficult to tell which subnet the frame is on. To keep the frames on each subnet separate, perform two separate captures on one computer in each subnet.
Altering the Connection State
After you have established a connection to a remote agent, the connection can exist in one of the following states:
• Suspended— You can suspend a connection only if you are capturing on a remote computer. Use this option if you are using an expensive or unreliable line. When you suspend a connection, the agent on the remote computer continues capturing.
• Reconnected— When you suspend a connection, you must reconnect to the remote agent to retrieve capture information.
• Disconnected— When you disconnect from the remote agent, any unsaved data on the remote computer is lost.
Capturing Network Packets on Multiple Agents
It is not possible to have more than one connection or more than one capture on the same agent. The Network Monitor refuses subsequent connections and does not allow a second capture. However, you can perform captures on different agents simultaneously. To do this on the same local machine, start multiple instances of Network Monitor, one for each capture.
Troubleshooting Network Monitor Agent Using the Remote Event Log
The easiest way to find out what the Network Monitor Agent is doing is to view the event log. There are nine messages sent to the event log:
• The Network Monitoring Agent service has successfully started.
• The Network Monitoring Agent service has successfully stopped.
• The Network Monitoring Manager manager_machine has connected.
• The Network Monitoring Manager has disconnected; the currently pending capture operation is continuing.
• The Network Monitoring Manager has disconnected; any currently pending operations have been stopped.
• The Network Monitoring Agent has failed to start. The Agent found no local network drivers to bind to.
• Network Monitoring is not installed correctly.
• The Network Monitoring Agent has failed to start. The Agent failed registration. The return code is Transport-specific return code.
Note: Microsoft Technical Support may use this return code to determine the cause of the problem.
• The Network Monitoring Agent has failed to start. The Agent could not find the NalAgentProc() entry point in Rnal.dll.
Systems Management Server Help Desk and Remote Diagnostic Tools
Systems Management Server also contains powerful help desk and remote diagnostic tools that allow you to take control of a users desktop and remotely control the screen, keyboard, and mouse. You can also run commands at a client computer, transfer files directly to a client computer, or even remotely restart a client computer. The Systems Management Server remote diagnostic capabilities allow you to monitor the client’s parameters such as client computer environment variables and memory use. These remote troubleshooting capabilities allow your organization to limit on-site support visits, making it possible for the same number of technicians to support a growing number of users.
The table below describes the remote diagnostic functionality of the help desk and diagnostic utilities provided in Systems Management Server version 1.2. SMS provides these diagnostic utilities for MS-DOS and all windows-based clients:
• CMOS Info
• Device Drivers
• ROM Info
• Interrupt Vectors
• DOS Memory
• Ping Test
In addition, SMS provides the following utilities for SMS clients running Windows for Workgroups 3.11, Windows 3.1 or 3.11, and Windows 95:
• Windows Memory
• Windows Modules
• Windows Tasks
• Global Heap
• GDI Heap
|Remote Diagnostic Tasks |Tool Name |
|View the display and take control of MS-DOS and Windows-based clients keyboard and |Remote Control |
|mouse remotely. | |
|Remotely restart an Systems Management Server client . |Remote Reboot |
|Converse through text with a remote Systems Management Server client. |Remote Chat |
|Transfer files between the Systems Management Server administrator computer and a |File Transfer |
|remote Systems Management Server client. | |
|Run an application on a remote Windows-based Systems Management Server client. |Remote Execute |
|Display CMOS information of remote Systems Management Server-based clients. Settings |CMOS Info |
|such as date, time, primary display, memory, and disk information can be retrieved | |
|remotely. | |
|Displays information about the device drivers loaded into memory on remote Systems |Device Drivers |
|Management Server-based clients. Information such as Device Address, Device Name, | |
|Entry Offsets, Fmt, I/O Ctl, and Description can be retrieved remotely. | |
|Provides information about all read-only modules (ROM) installed on remote Systems |ROM Info |
|Management Server clients. Information such as the name, address, size, hooked | |
|interrupt vectors, and ROM strings can be retrieved remotely. | |
|Displays the interrupt vector table for remote Systems Management Server clients. The|Interrupt Vectors |
|interrupt vector table is the master MS-DOS table for all hardware and software | |
|interrupts. | |
|Provides information about which programs are currently loaded into conventional and |DOS Memory |
|upper memory on remote Systems Management Server clients. Information such as Program| |
|Segment Prefix (PSP), Program size, Program name, Hooked Interrupt Vectors, Parent | |
|Process ID, Environment Segment, File Handle Count, File Handles, and Values list can| |
|be retrieved remotely. | |
|Tests the network connection between the Systems Management Server administrator |Ping Test |
|computer and remote Systems Management Server clients. The connection is tested by | |
|sending packets from one computer to the other as fast as possible. The Ping Test | |
|utility displays the following information: test time, total packets, packets/second,| |
|and total errors. | |
|Displays how memory is allocated on the remote Systems Management Server client. The |Windows Memory |
|Windows Memory utility displays the following information: largest free block, | |
|windows memory, swap file, and system heaps. | |
|Provides information on the system or program modules on remote Systems Management |Windows Modules |
|Server clients. The module list includes drivers, dynamic-link libraries (DLLs), and | |
|any other active applications on the remote client. The Windows Modules utility | |
|displays the following information: handle, use count, path, and memory objects. | |
|Provides information about Windows-based programs that appear in the Task List of |Windows Tasks |
|remote Systems Management Server clients. The Windows Tasks utility displays the | |
|following information: handle, instance, module, queue location, queue size, events | |
|waiting, current directory, and command line. | |
|Displays a list box containing the Windows classes used in programs running on the |Windows Classes |
|remote Systems Management Server client. The following information is provided: | |
|Style, Window Proc Address, Extra Class Bytes, Extra Window Bytes, and Instance. | |
|Displays memory objects and identifies the program module that owns the particular |Global Heap |
|object on remote Systems Management Server clients. The following parameters for | |
|selected memory objects are provided: Handle, Address, Size, Lock Count, Page Lock | |
|Count, PDB Owner, Local Heap, Owner, Object Type, and Contents. | |
|Displays GDI Heap information on remote Systems Management Server clients. The |GDI Heap |
|following information is provided: Type, Size, Address, Handle, Flags, Fixed, Free, | |
|Movable, and Lock Count | |
For more information on Microsoft Systems Management Server and Network Monitor:
• Visit the Management section of the Microsoft Web Site at .
• Visit Microsoft’s online Knowledge Base at .
• See the Systems Management Server Administrator's Guide.
Microsoft’s Future Remote Management and Diagnostic Strategy
The Microsoft Management Console
The Microsoft Management Console (MMC) is a display framework for hosting management tools packaged as MMC snap-ins. MMC will be a core part of Microsoft's future management strategy, and will be the common shared host for management tools for current and future versions of Windows, Windows NT, and the BackOffice® family.
The Console and the Role of Snap-ins
MMC itself does not provide any management behavior, but instead provides a common environment for snap-ins, which will be written by both Microsoft and independent software vendors (ISVs). Snap-ins provide the actual management behavior. The MMC environment provides for seamless integration between snap-ins, even those provided by different vendors.
MMC can be used from within an existing enterprise console or to launch enterprise consoles. Snap-ins can work independently or can extend functionality of other snap-ins. A system administrator can use a series of snap-ins to create task-oriented administrative displays customized to provide the appropriate management functions, and can then use these customized snap-ins to organize work flow or for task delegation.
By allowing administrators to create their own views and by removing technology discipline boundaries, it is possible to create appropriate displays of network, systems, and user information — providing a single point of management that is integrated, comprehensive, and easy to use. Providing a more powerful centralized point of management, and consistency in management tools, has been one of the most requested items from our customer base. MMC provides a solution and a framework that addresses this need for our customers across the Microsoft Windows and BackOffice product lines.
Key Benefits of Using MMC
Microsoft Management Console benefits systems administrators as follows:
• Task Orientation. The tools being defined to work with MMC are task-oriented—they are designed to complement the task being performed rather than merely display raw objects that can be manipulated. Also, because administrators can customize their tools using pieces from a variety of vendors, they can create consoles that contain only the elements they need to complete their tasks. (Note that task orientation and customization will be implemented through the taskpad feature of MMC, which is scheduled to be released in the Windows NT 5.0 timeframe.)
• Integration. The user interface (UI) for all the management tasks an administrator must perform is collected into a single console. As new applications are added to a computer or network, their management features are integrated into the existing management common console.
• Delegation. Administrators can easily modify existing tools to create new tools with reduced functionality and less complex views of the tool name space, and then give these tools to others. A person who receives such a tool is presented with a simpler, more manageable view of the tasks he or she is being asked to perform.
• Overall Interface Simplification. All tools built for MMC—from any software vendor—will have a similar look and feel, making it easier for users to use all tools after learning one. Because you can mix and match tools from any vendor, you can use the best tools available from each management product category. MMC also enables a single piece of software to provide functionality across the interface in a consistent manner.
• Remote functionality. Most of the snap-ins that are being developed by Microsoft will have remote capabilities. In future versions of Windows NT, Microsoft plans to take traditional stand-alone tools such as Control Panel and migrate the administrative Control Panel tools to MMC snap-ins. In the process, these management tools will also then support remote management.
MMC is also flexible. Saved console files are not tied to large amounts of managed data, so it is practical for a system administrator to create multiple console files and then share them by e-mail, on floppy disks, or over the network. An administrator can assemble multiple snap-ins into a tool, which the administrator can save as a Management Saved Console (.msc) file. The administrator can then reload the file later to instantly re-create the tool. The .msc file can also be sent through e-mail to another administrator, who can then load the file and use the resulting tool. Note that if the second administrator does not have all the necessary snap-ins installed on his or her computer, MMC will automatically download the needed snap-ins when the second administrator loads the .msc file.
For more information on MMC, visit the Management section of the Microsoft Web site at .
Microsoft Active Directory
Microsoft is committed to enhancing its current Windows NT Server directory services in the next release of Windows NT Server. Windows NT 5.0 includes a newly designed directory service called the Active Directory. The Active Directory extends the features of previous Windows-based directory services and adds entirely new features.
The Active Directory is secure, distributed, partitioned, and replicated. It is designed to work well in any size installation, from a single server with a few hundred objects to thousands of servers and millions of objects. The Active Directory adds many new features that make it easy to navigate and manage large amounts of information, generating time savings for both administrators and end users. These features include a new domain model and hierarchical name space
The User Interface and Management Tools
Administrators and end users need different user interfaces. Many properties and actions have no meaning to end users, yet administrators need access to them. Moreover, in Windows NT 5.0, security and administrative policies prohibit end users from viewing or changing many attributes. Thus, the Windows NT 5.0 directory will present a different UI to administrators and end users. The administrative UI will be presented through different MMC snap-ins—specifically, Microsoft Directory Service Manager, Microsoft Site and Replication Manager, and Microsoft Active Directory Schema Manager.
The Directory Service Manager snap-in will provide a consistent mechanism for administrators to add users, manage printers, and control servers. It will be available as a snap-in for MMC and as a Directory Server Management Web Browser tool, for use from any framescapable browser with support for Kerberos authentication. The end user will see the directory through the Windows operating system shell. For the user, the Network Neighborhood folder on the Desktop will lead to the Directory folder.
Windows NT 4.0 is capable of storing up to 40 megabytes (MB) of objects for each domain, which allows up to 40,000 users for each domain in the registry-based security account manager (SAM). Because Windows NT 4.0 uses a flat list organization for the name space, administering a very large domain can be difficult. Administrative tools, such as the User Manager for domains, cannot start and display all objects quickly. Moreover, data represented in a flat list makes it hard to find a particular object. To allow simpler, more flexible administration, the Windows NT 5.0 directory uses a structured database, based on Microsoft Exchange Server directory storage as its data store. Using the Extensible Storage Engine (ESE) allows the directory to scale up to 10 million objects in a single data store, overcoming the limitations of the registry-based SAM database in Windows NT 4.0. The Directory Service Agent (DSA) runs on top of the flat database and implements a hierarchical name space. With this hierarchical name space, the Active Directory takes the existing domain model forward to a new “tree of trees” model. By organizing the name space into a hierarchy, you no longer need to view tens of thousands of users in a flat list.
A Single Point of Administration
The Active Directory allows a single point of administration for all published resources, which can include files, peripheral devices, host connections, databases, Web access, users, other arbitrary objects, services, and so forth. It uses the Internet Directory Name Space as its locator service, organizes objects in domains into a hierarchy of organizational units (OUs), and allows multiple domains to be connected into a tree structure. Administration is further simplified because there is no notion of a primary domain controller (PDC) or backup domain controller (BDC). The Active Directory uses domain controllers (DCs) only, and all DCs are peers. An administrator can make changes to any DC, and the updates will be replicated on all other DCs.
The overriding goal of the Active Directory is to provide a unified view of the network that will greatly reduce the number of directories and name spaces with which network administrators (and users) must contend. The Active Directory is specifically designed to subsume and manage other directories, regardless of their location or their underlying operating system(s). To accomplish this, the Active Directory provides extensive support for existing standards and protocols, including standard name formats, and provides application programming interfaces (APIs) that facilitate communication with these other directories.
The Active Directory uses the Domain Name System (DNS) as its name system, and can exchange information with any application or directory that uses Lightweight Directory Access Protocol (LDAP) or Hypertext Transfer Protocol (HTTP).
Increased Management Granularity
The robust domain trees provided by the Active Directory offer far greater management flexibility than the single tree organizational structures of other directory services. Although single tree domains can be built with the Active Directory, a better administrative option is to build a tree of domains, each with its own security boundary. A hierarchy of domains allows for finer granularity of management without compromising security. Permissions can flow down the tree, with users being granted permissions (as well as granting permissions to others) on an organizational unit basis. This domain-tree structure easily accommodates organizational change with pruning, grafting, and merging.
Each domain in a domain tree has a copy of the directory service holding all objects for that domain and metadata about the domain tree, such as the schema, list of all domains in the tree, location of global catalog servers, and so forth. Because a single directory service store does not have to hold all objects for all domains, very large trees can be built without compromising performance.
Increased Security Granularity
The Active Directory provides the fine-grained management structure that allows for decentralized management without compromising security. Because each domain is a security boundary, multiple security boundaries are possible. With this design, administrators in domain A are not automatically administrators in domain B. The container hierarchy is important because, today, the scope of management is the domain, and the administrator of a domain has authority over every object and service within that domain. The Active Directory grants privileges to users based on the specific functions they must perform within a given scope. Management scope can include an entire domain, a subtree of OUs within a domain, or a single OU.
With the Active Directory, very large structures of users can be created in which each user can potentially access all of the information stored in the directory, but the security boundaries remain clear. Security boundaries can also be much smaller than domains. For example, when a user account is created, it is associated with a particular domain, but it can also be put into an organizational unit. Permission to create users in an organizational unit can be delegated, allowing someone to create users or other directory objects in one place only, with rights within that OU only. In addition, OU hierarchies can be created. The Active Directory introduces very specific permissions, all of which can be delegated and restricted in scope.
A Unified Directory
The Active Directory integrates the Internet concept of a name space with the operating system’s directory services, thus allowing enterprises to unify and manage the multiple name spaces that now exist in the heterogeneous software and hardware environments of corporate networks. It uses LDAP as its core protocol and can work across operating system boundaries, integrating multiple name spaces. It can subsume and manage application-specific directories, as well as other NOS-based directories, to provide a general-purpose directory that can reduce the administrative burden and costs associated with maintaining multiple name spaces.
Note that the Active Directory is not an X.500 directory. Instead, it uses LDAP as its access protocol and supports the X.500 information model, without requiring systems to host the entire X.500 overhead. The result is the high level of interoperability required for administering real-world, heterogeneous networks.
API Support
The Active Directory provides powerful, flexible, and easy-to-use application programming interfaces (APIs). The availability of a rich set of APIs for the directory service encourages the development of applications and tools that make use of the directory’s services.
The Active Directory includes three major API sets:
• ADSI, the Active Directory Service Interfaces, a set of component object model (COM) interfaces for manipulating and querying multiple directory services.
• MAPI, the Windows Open Services Architecture Messaging API.
• LDAP C API (RFC 1823), an informational RFC that is the de facto standard in C programming for LDAP applications.
To make it easier to write directory-enabled applications that access the Active Directory and other LDAP-enabled directories, Microsoft developed Active Directory Service Interfaces (ADSI). ADSI is a set of extensible, easy-to-use programming interfaces that can be used to write applications to access and manage the following:
• Active Directory
• Any LDAP-based directory
• Other directory services in a customer’s network, including the NetWare Directory Service (NDS)
ADSI is part of the Open Directory Services Interface (ODSI), the Windows Open Services Architecture (WOSA) architecture for manipulating and querying multiple directory services. ADSI objects are available for Windows NT 4.0, Novell NetWare 3.x and 4.x, and the Active Directory, as well as any other directory service that supports the LDAP protocol.
Active Directory Service Interfaces abstract the capabilities of directory services from different network providers to present a single set of directory service interfaces for managing network resources. This greatly simplifies the development of distributed applications, as well as the administration of distributed systems. Developers and administrators use this single set of directory service interfaces to enumerate and manage the resources in a directory service, no matter which network environment contains the resource. Thus, ADSI makes it easier to perform common administrative tasks, such as adding new users, managing printers, and locating resources throughout the distributed computing environment, and ADSI makes it easy for developers to “directory enable” their applications.
ADSI objects are designed to meet the needs of three main audiences:
• Developers. Typically, this audience will use ADSI with a compiled language such as C++, although Microsoft Visual Basic® can be used for prototyping the application. For example, a developer could write an application to manage multiple directories, network printing, back up databases, and so on.
• System administrators. Typically, this audience will access ADSI through a scripting language, such as Microsoft Visual Basic, although C/C++ can also be used to enhance performance. For example, with Active Directory an administrator could write a script to add 100 new users to the system and establish them as members of selected security groups.
• Users. As with system administrators, this audience will access ADSI through a scripting language. For example, a user might write a script to locate all print jobs in a group of print queues and display the status of each.
Summary of Microsoft Active Directory Features and Benefits
The Active Directory includes the following features and benefits:
• Support for open standards to facilitate cross-platform directory services, including support for the Domain Name System (DNS) and support for standard protocols, such as LDAP and HTTP.
• Support for standard name formats to ensure ease of migration and ease of use.
• A rich set of APIs, which are easy to use for both the scripter and C/C++ programmer.
• Simple, intuitive management through a simple hierarchical domain structure, and the use of drag-and-drop administration.
• Directory object extensibility through an extensible schema.
• Fast lookup and Internet publishing through the global catalog.
• Speedy, convenient updates through multimaster replication.
• Support for services that have a short life span such as chat services, IP telephony, as well as other conferencing services.
• Backward compatibility with previous versions of the Windows NT operating system.
• Interoperability with NetWare environments.
For more information on Microsoft Active Directory, visit the Management section of Microsoft’s Web Site at .
Microsoft Windows Scripting Host (WSH)
The Windows Scripting Host (WSH) is a language-independent scripting host for 32-bit Windows platforms. Windows Scripting Host is currently available as an add-on for Windows 95 and Windows NT 4.0. Windows Scripting Host is scheduled to be integrated into future releases of Windows, Windows NT Workstation, and Windows NT Server.
WSH can be run from either the Windows-based host (Wscript.exe), or the command shell-based host (Cscript.exe). Windows Scripting Host enables scripts to be run directly on the Windows desktop or command console, without the need to embed those scripts in a HyperText Markup Language (HTML) document. Scripts can be run directly from the desktop simply by clicking on a script file, or from the command console. WSH provides a low-memory scripting host that is ideal for non-interactive scripting needs, such as logon scripting, administrative scripting, and so on. WSH provides the capability of batch automating many of the remote management and diagnostic functions of the tools listed in this document.
For more information on Windows Scripting Host, visit the Management section of Microsoft’s Web Site at .
Web-based Enterprise Management (WBEM) and Windows Management Instrumentation (WMI)
Effective management—whether performed locally or remotely—requires well-instrumented computer software and hardware components so that subsystem components can be monitored and controlled. Microsoft is committed to simplifying instrumentation of hardware and software for the Windows environment, and is also committed to providing consistent access to this instrumentation for Windows-based management
WBEM provides fully integrated operating system support for uniform system and applications management based on the Common Information Model (CIM) adopted by the Desktop Management Task Force. WBEM can provide a consistent, descriptive model of the configuration, status, and operational aspects of Windows NT systems, and management applications can use WBEM to create solutions that reduce the maintenance and life cycle costs associated with managing Windows NT. Used in conjunction with other management services provided in Windows NT, such as MMC, WBEM helps simplify the task of developing well-integrated management applications, allowing vendors to provide Windows NT customers with enterprise scalable management solutions. Local and remote eventing combined with a SQL-based query language to the information model provides the means to create management applications for Windows.. The ability to easily script these solutions in Visual Basic or using Windows Scripting Host (WSH) adds an often-requested dimension to Windows NT management.
Windows Management Instrumentation (WMI) provides the basis for hardware instrumentation in future Windows environments. WMI is a kernel-level instrumentation technology for the Windows platform. Close coupling of WMI with services developed to conform to the Web-Based Enterprise Management (WBEM) initiative will allow Microsoft to simplify instrumentation and provide consistent, open access to management data. (Both WMI and WBEM are key components in Microsoft’s manageability and total cost of ownership containment efforts.) WMI is integrated into both the Windows 98 and Windows NT 5.0 kernel to provide driver data and events. WMI is an extensible design, and an original equipment manufacturer (OEM) or independent hardware vendor (IHV) can extend the instrumented data set.
What Does WMI Do?
WMI publishes information, configures device settings, and supplies event notification from device drivers. WMI is part of the WDM driver architecture, and distributes the following data:
• Published data—A standard set of WMI data will be built into the Windows NT 5.0-supplied port/class drivers.
• Custom data—Provided through original equipment manufacturer/independent hardware vendor (OEM/IHV) driver extensions.
• Secure data—Provided through Windows NT security descriptors for a designated usage.
• Expensive data (optional)—Some data collection activity can significantly affect the performance of the driver; this data should only be collected when the management application specifically requests it. By default, a driver will not collect the expensive data. When a management application using WBEM expresses interest in that expensive data, WMI signals the driver to start collecting the data. WMI also keeps a reference count and signals the driver to stop collecting the data when the last WBEM application interested in that data terminates. An important point to note is that the driver writer, not WMI, decides what data is expensive to collect. And the mechanism for indicating that data is expensive to collect is extremely simple.
• Event Notifications—Event notification is a key feature of WMI, allowing drivers to detect hardware events and/or errors. An event can then be passed to WBEM for corrective action based on the specific event that occurred. For example, a disk driver has an abnormally high amount of disk write/read errors, and it sends an event notification to a disk management utility. As another example, a Network Interface Card (NIC) detects the loss of Ethernet signal, and sends notification to a consumer of management data that is watching for events that affect the network.
WMI also allows a management application to configure a device. A management application may need to reconfigure a device based upon some driver-raised event or because of the data collected by the management application.
Note that the two key features of WMI are its extensibility and its event notification mechanism. WMI allows an IHV to extend the instrumentation data set and add value to a hardware/software solution. In addition, WMI provides a means for the driver writer to provide adequate notification of driver events, thereby eliminating situations where the driver detects a potentially disastrous situation and can only write an entry to the event log.
How Does WMI Work with WBEM?
WMI provides WBEM with yet another means for collecting and setting data and events. WBEM is a unifying architecture that allows access to data from a variety of underlying technologies—including Win32, WMI, the Desktop Management Interface (DMI), and SNMP. WBEM is based upon the Common Information Model (CIM) schema, which is an industry standard driven by the Desktop Management Task Force (DMTF). WBEM details can be obtained from .
WBEM provides a three-tiered approach for collecting and providing management data. This approach consists of a standard mechanism for accessing data (using the DMTF CIM schema), a common protocol for obtaining and disseminating management data—COM/DCOM, and a series of modules known as WBEM providers, which map each standard and proprietary instrumentation mechanism into WBEM.. A WBEM provider supplies instrumentation data for parts of the CIM schema. In addition to WBEM providers being made available by Microsoft, Intel, and others for SNMP and DMI, Microsoft has developed a WMI provider that interfaces with the kernel mode WMI component. The kernel mode WMI component provides services that allow WMI-enabled drivers to implement WMI, and also acts as an interface to the WMI provider.
WMI was developed to provide a set of instrumentation capabilities that are tightly linked to the driver models found in Windows operating systems. Additionally, because WMI uses the same schema as WBEM, it integrates extremely well into the three-tiered approach to instrumentation infrastructure.
Microsoft will ship core WMI support in the operating system kernel and in a WMI driver for Windows 98 and for Windows NT 5.0.
More details about WBEM are available from the Management section of Microsoft’s Web Site at .
Resources and Where to Find Additional Information
Resources
Descriptions and how to use the remote management and diagnostics tools included with Windows NT Workstation 4.0 are found in Online Help Files, the Windows NT Server Start Here guide and Books Online (Concepts and Planning and Networking Supplement).
For directions on using Online Help, see Part 1: Introduction, Chapter 2, "Learning the Basics, Getting Online Help," in the Windows NT Server Start Here guide.
The Windows NT Server Start Here guide includes the following management information:
• Chapter 3, "Learning the More Advanced Features, Using Administrative Tools"—includes discussions of Event Viewer, Network Client Administrator, Performance Monitor, Remote Access Admin, and Windows NT Diagnostics.
• Chapter 4, "Learning Networking Basics, Using Dial-Up Networking"—includes instructions on how to use a modem to access shared resources (files, printers) on another network.
• Chapter 7, "Connecting to the Network"—provides information on configuring the computer to use Windows NT networking features.
For directions on using Books Online, see Part 1: Introduction, Chapter 1, "Welcome, Finding Information About Windows NT Server," in the Windows NT Server Start Here guide.
Books Online Concepts and Planning includes information on:
• Remote-boot server support for MS-DOS and Windows 3.x clients, interactive and remote logons, user authentication for remote logons, forcibly disconnecting remote users from a server
• Remote user domain management, directory replication
• System policy and registry editing
• Licensing manager
• Dynamic Host Configuration Protocol (DHCP) management
• NTBackup utility
• Alerter service
• Event Viewer
• File Transfer Protocol (FTP)
• Print server management
• Monitoring network performance, including Simple Network Management Protocol (SNMP) services
• Windows NT diagnostics
Books Online Networking Supplement includes information on:
• TCP/IP diagnostic tools (arp, hostname, ipconfig, lpq, nbstat, ping, route, and tracert) to detect and resolve TCP/IP networking problems
• Administrative tools, including Internet Information Server for setting up Internet and intranet web sites, Dynamic Host Configuration Protocol (DHCP) service, Windows Internet Name Service (WINS), Domain Name System (DNS) server, and TCP/IP printing
• WINS RAS and backup name server parameters
• Printer management
• Event Viewer
• Terminal emulation using RAS, Hyperterminal
• IPX routing
• Using log files as a diagnostic tool
• RAS routine maintenance tasks (by conveying real-time information about users, ports, modems, and data transmissions, the Remote Access Administrator’s utility simplifies the monitoring of servers and users and provides valuable clues that assist in troubleshooting. Running the utility continuously allows administrators to track activity on remote access servers and respond promptly to problems with user accounts and hardware.)
• Monitor servers and users systematically with Remote Access Administrator
• Reviewing Windows NT Server Event Viewer to verify that network security is intact
• Viewing status and connection information with Dial-Up Networking Monitor
• Remote Access Administrator’s utility
• Managing multiple Remote Access servers from a central location
• Monitoring user activity on all remote access servers in the domain
Descriptions and how to use the remote management and diagnostics tools included with Systems Management Server are found in the Systems Management Server Administrator's Guide and the Systems Management Server online Help.
The Systems Management Server Administrator’s Guide includes the following information.:
• Chapter 10, "Remote Troubleshooting," includes information on:
1. Configuring a Remote Control Client
2. Configuring Protocol Settings
3. Configuring remote Support across a router
4. Using the Microsoft Remote Access Service (RAS)
5. Help Desk and Diagnostic Utilities provided in Systems Management Server: Remote Desktop Control, Remote Reboot, Remote Chat, File Transfer, Remote Execute, and Diagnostic utilities that gather information about hardware, system information, and software configuration settings.
6. Troubleshooting
7. How Systems Management Server integrates with the Windows NT Management Tools
Chapter 11, "Microsoft Network Monitor," includes information on:
8. Requirements for Using Network Monitor
9. How Network Monitor Works
10. Starting and Stopping Network Monitor
11. Setting Triggers and Alerts
12. Displaying Network Monitor Captures.
13. The Network Monitor Agent
14. Requirements for the Network Monitor Agent
15. Network Monitor Agent Topologies
16. Installing, Starting, and Stopping the Network Monitor Agent
17. Capturing On the Network Monitor Agent
18. Altering the State of the Network Monitor Connection
19. Network Monitor and Token Ring Networks
More Information
For the latest information on Windows NT Server, please visit our World Wide Web site: or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).
The Windows NT Server 4.0 Resource Kit can be found at .
The Windows NT Server 4.0 resource link preview can be found at .
Windows NT Server white papers can be found in the Technical Papers section of and at .
For the latest information on the BackOffice line of products, please visit our World Wide Web site at .
Visit the Management section of Microsoft’s Web Site at .
Visit Microsoft’s online Knowledge Base at .
Appendix A
Windows NT Workstation comes with a subset of the Windows NT Server administrative tools focused toward the needs of a workstation user and administrator. These tools can be used to solve system management problems remotely. The charts below list the Windows NT Workstation management and diagnostic tools that have remote capabilities in alphabetic order.
Remote Functionality of Management Tools in Windows NT Workstation 4.0
|Tool Name |Remote Functionality |Type |
|Chat (Chat.exe) |Allows two computers to connect and participate in a text conversation. |GUI |
|Clipboard Viewer |Connects and disconnects from a remote computer’s clipboard and allows the clipboard |Service, GUI|
|(Clipsrv.exe and |contents to be shared and transferred. | |
|Clipbrd.exe) | | |
|Dial-up networking |Establishes a dial-up networking connection to a remote system. |GUI |
|(Rasphone.exe) | | |
|Find Command (built into |Finds computers, files, folders, text strings, and more, using a variety of search |GUI |
|Explorer.exe) |criteria. | |
|Command prompt - |Adds and modifies user accounts and local and global group accounts. Sends text and |CMD |
|net commands |administrative alerts between two or more computers. Connects and disconnect from | |
| |remote shared resources. Sets the computer’s internal clock from a remote source. Views| |
| |and browses shared resources. Views printer and print job queue status information. | |
|NT Backup (Ntbackup.exe) |Backs up and restores data and system files. Note that you must connect to network |GUI |
| |shares before starting the NTBackup utility. | |
|Printers folder |Same functionality as local. Complete printer management. Adds new printers, changes |GUI |
|(Control.exe printers) |document properties, changes printer configuration settings, sets security, pauses | |
| |printing, removes hung print jobs, purge printers, and more. | |
|Remote Access Admin |Same functionality as local. Manages the RAS server service, configure dial in user |GUI |
|(Rasadmin.exe) |security, monitors and manages user connections. | |
|Run Command (built into |Accesses computers and shared resources, runs programs, open files and folders remotely|GUI |
|Explorer.exe) |using UNC commands from a command prompt. | |
|Telnet client (Telnet.exe) |Provides remote terminal emulation so that applications can be run on the remote |GUI |
| |system. Note that you must install a Telnet Daemon server on the remote computer before| |
| |the client can connect. | |
|Windows NT Explorer, My |File and folder management. Connects and disconnects from remotely shared resources and|GUI |
|Computer, Network |allows file manipulation. | |
|Neighborhood (built into | | |
|Explorer.exe) | | |
Diagnostic Tools and Services in Windows NT
Workstation 4.0
|Tool Name |Remote Functionality |Type |
|Alerter (Alrsvc.dll) |Sends administrative alerts to other systems or users. |Service |
|API Profiler (Apimon.exe) |User mode debugging tool that supports attaching to applications remotely to trace API |GUI |
| |calls. | |
|Directory Replication |Imports files and directories from remote Windows NT systems. |Service |
|(Lmrepl.exe) | | |
|Event Viewer (Eventvwr.exe) |View event message logs for System, Security, and Application events. Supports filtering|GUI |
| |and saving to file. | |
|File Transfer Protocol |RFC compliant bi-directional TCP/IP-based file transfer program. |CMD |
|(Ftp.exe) | | |
|Find String (Findstr.exe) |Finds strings in files. |CMD |
|Hyperterminal (Hypertrm.exe)|Connects to remote systems via dial up. Can be used to diagnose modem connectivity |GUI |
| |problems. | |
|IPX Route (Ipxroute.exe) |IPX routing and source routing configuration program. Allows you to troubleshoot IPX |CMD |
| |routing problems. | |
|Kernel Debugger (I386kd.exe)|Kernel mode debugging tool. Note that Remote.exe from the Windows NT resource kit must |CMD |
| |be used for remote functionality. | |
|Line Printer Queue (Lpq.exe)|Allows you to monitor the status of a print queue on a host running the Line Printer |CMD |
| |Daemon (LPD) server. | |
|Line Printer Remote |Allows you to configure TCP/IP printing options for clients and view print job status on|CMD |
|(Lpr.exe) |servers providing the Line Printer Daemon (LPD) server. | |
|Name Server Lookup |Allows you to test and view DNS information for TCP. Allows you to troubleshoot host |CMD |
|(Nslookup.exe) |name resolution problems. | |
|Net Commands (Net.exe) |Issues network commands from the command prompt. Remote functionality on a computer |CMD |
| |running Windows NT Workstation includes adding local and global groups and users, | |
| |viewing connecting and disconnecting from resource shares, controlling print jobs, | |
| |synchronizing the computer's clock from a remote system, and sending messages to other | |
| |users or computers on the network. | |
|NetBIOS Statistics |Provides important protocol statistics and TCP/IP NetBIOS over TCP/IP connection status |CMD |
|(Nbtstat.exe) |information for remote troubleshooting. This tool is typically used to identify | |
| |conflicts in NetBIOS names, conflicts in network interface card (NIC) media access | |
| |control addresses and NetBIOS name registration problems. | |
|Network Monitor Agent |Allows a computer to act as a network sniffing for Network Monitor. |Service |
|(Nmagent.exe) | | |
|Performance Monitor |Graphical tool for measuring system performance. Many objects are available for tracking|GUI |
|(Perfmon.exe) |such as memory, processor, cache, and threads. Can create alerts and log data to a file.| |
|Ping (Ping.exe) |Sends network packets using the TCP/IP protocol to a remote system and listens for a |CMD |
| |response. Helps determine if a remote system is active on the network. | |
|Registry Editor |Supplemental registry editor. Run to edit, view, and search, on registry keys. Note: |GUI |
|(Regedit.exe) |This version has enhanced search capabilities but does not support setting security on | |
| |registry hives or keys. | |
|Registry Editor 32 |Run to edit, view, search, and set security on registry keys. Can also be used to gather|GUI |
|(Regedt32.exe) |system and software information. | |
|Remote Access Service |Allows computers to dial up and remotely access one server or all systems on the |Service |
|(Rassrv.exe) |network. | |
|Remote Copy Protocol |Copies files between a computer running Windows NT and the host system without logging |CMD |
|(Rcp.exe) |on. Note: Windows NT does not contain the server side component. | |
|Remote Execute (Rexec.exe) |Runs a process on a remote host system. Note: Windows NT does not contain the server |CMD |
| |side component. | |
|Remote Shell (Rsh.exe) |Remote Shell allows you to run commands on a remote host system without logging on. |CMD |
| |Note: Windows NT does not contain the server side component. | |
|SNMP Agent (Snmp.exe, |Provides network management over TCP/IP and IPX and sends traps of critical events to |Service |
|Snmptrap.exe) |SNMP management stations. | |
|Trace Route (Tracert.exe) |Traces and reports each router or gateway crossed by a TCP/IP packet on its way to a |CMD |
| |remote host. | |
|Trivial File Transfer |Trivial FTP uses UDP instead of TCP to provide bi-directional file transfers. |CMD |
|Protocol (Tftp.exe) | | |
|User Mode Debugger (Cdb.exe)|User mode debugging tool that is remote capable, similar to NTSD. Remote.exe from the |CMD |
| |Windows NT resource kit must be used for remote functionality. | |
|Windows NT Diagnostics |Graphical view of Windows NT-based system information. Shows you version, system, |GUI and CMD|
|(Winmsd.exe) |display, service, resource, environment, and network information from a remote | |
| |Windows NT-based system. | |
Appendix B
Windows NT Server includes all of the management tools that Windows NT Workstation includes with the following additions and changes. These tools can be used to solve system management problems remotely. The charts below list the Windows NT Server management and diagnostic tools that have remote capabilities in alphabetic order.
Remote Functionality of Management Tools in Windows NT Server 4.0
|Tool Name |Remote Management Tasks |Type |
|DHCP Manager (Dhcpadm.exe) |Administers DHCP servers. Adds and deletes DHCP servers; configures remote DHCP client |GUI |
| |workstations. Adds, activates, reserves, and deletes client IP addresses. | |
|Directory Replication |Imports and exports files and directories to and from remote Windows NT-based systems. |Service |
|(Lmrepl.exe) | | |
|DNS Manager (Dnsadmin.exe) |Administers DNS servers, views DNS server information, and adds DNS resource records. |GUI |
|License Manager (Llsmgr.exe)|Configures where license information is replicated to, including the ability to send all|GUI |
| |licensing information to a single “enterprise” server. | |
|System Policy Editor |Allows you to establish system policies to enforce policy rules for all computers in a |GUI |
|(Poledit.exe) |domain or individual computers. Profile restrictions can be set on individual users or | |
| |groups. Policy editor can also remotely edit certain registry settings on both system | |
| |and user settings. | |
|User Manager for Domains |Manages domain user accounts and policies. Connects to remote domains; adds, deletes, |GUI |
|(Usrmgr.exe) |and edits users and groups. Configures user-specific logon information such as logon | |
| |properties. | |
|WINS Manager |Administers WINS servers. Adds and deletes servers, changes and views server and |GUI |
|(Winsadmin.exe) |replication partner configuration. Views summary and detailed status information on the | |
| |WINS database. Shows database records; initiates database scavenging; adds, edits, | |
| |deletes, and imports static mappings. | |
Diagnostic Tools and Services Included in Windows NT Server 4.0
|Tool Name |Remote Functionality |Type |
|Log Viewer (Logview.exe) |Lets you open multiple diagnostic log files at one time. |CMD |
|Network Monitor (Netmon.exe) |Captures networking packets and analyze them from remote Network Monitor agents. |GUI |
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- troubleshooting group policy in windows 2000
- 3 system administrator isso interview questions
- remote management and diagnostics
- ch 1 introducing windows xp
- magtek device drivers for windows programming reference
- important details
- command line reference for oracle windows linux and os x
- step by step guide to managing the active directory
Related searches
- debt management and collections system
- financial management and reporting syste
- project management and customer service
- financial management and strategic planning
- strategic management and innovation
- debt management and collection services
- debt management and collections stud
- strategic management and planning
- management and its importance
- innovation management and entrepreneurship
- financial management and management accounting
- department management and collections system